On Thu, Aug 23, 2018 at 12:15 AM, Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 23/08/18 01:13, Joel Sherrill wrote: > >> >> >> On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <chr...@rtems.org <mailto: >> chr...@rtems.org>> wrote: >> >> On 22/08/2018 22:25, Sebastian Huber wrote: >> > On 22/08/18 14:06, Joel Sherrill wrote: >> >> On Wed, Aug 22, 2018, 6:47 AM Sebastian Huber >> >> <sebastian.hu...@embedded-brains.de >> <mailto:sebastian.hu...@embedded-brains.de> >> >> <mailto:sebastian.hu...@embedded-brains.de >> <mailto:sebastian.hu...@embedded-brains.de>>> wrote: >> >> >> >> It really is necessary to know how the other architectures >> implement it. Some >> >> may turn out to be easy. Others like Epiphany and new may never >> matter. >> > >> > If the niche architectures don't use libbsd (which I guess is >> the case), then >> > there is no issue at all. >> > >> >> Do we document what is supported and what is not supported? >> >> >> This was largely the point of my response. We don't have a master list of >> at least the following information: >> >> + Architectures that support SMP and tested to N cores >> + Architectures that support TLS >> > > We have the CPU Supplement. You seem to be missing my point entirely. I am not saying the information is not available at all. I am saying that there is no central place that captures the status of SMP, TLS, libbsd for all architectures. This is a marketing and project planning issue -- not a per-architecture documentation issue. >From a new user's perspective, where do they get the easy answer to what's supported on what architectures? >From the perspective of someone looking for a project, where's the list of things that need to be done? >From the perspective of considering deprecating an architecture, support for TLS could be a factor. Without a master list to check against, there is no easy answer. Master list unfortunately needs to exist in two forms: + the marketing view which is likely a table. + the project planning view which is well served by a set of tickets to add TLS per architecture. > > > + Architectures that support libbsd >> >> A user can't determine what is usable to them in for at least those >> features. We need a basic feature table of at least the above >> for users. >> > > I think a better question is what do I have to provide to get libbsd > support? This is currently not that much. You just need the interrupt > extensions API. After the update to a new FreeBSD version you probably need > also TLS and maybe uni-processor architectures are no longer supported. You > can still use the current libbsd. > > >> Beyond that, I would consider TLS a hidden basic feature since I think >> we now rely on it in some infrastructure pieces (language run-times?). >> We don't have ticket(s) related to which architectures need it added. >> And no notes on how to extract the details on what to do from GCC. >> I randomly checked gcc for the nios2 and guess that this is the >> register: >> >> (TP_REGNO 23) ; Thread pointer register >> >> How I am supposed to figure that out reliably, I am not sure. >> >> I checked the bfin and don't get any hits for tls/TLS or THREAD_LOCAL. >> Perhaps it doesn't support it at all. Who knows? >> > > You have to check the ABI document. And as an odd note, I found what I think is the Blackfin ABI and it doesn't even mention TLS or thread local. https://docs.blackfin.uclinux.org/doku.php?id=toolchain:application_binary_interface > > > >> >> Does libbsd have suitable checks on the built RTEMS to know it >> cannot be supported? >> >> >> Without the above table, I am not sure how. Curious to hear Sebastian's >> answer. >> >> >> FWIW I do not think the idea of "one size fits all" is workable. I >> think a >> number of architectures would benefit from a different smaller >> networking stack. >> >> >> +1 >> >> We are in a position where we need begin to deprecate the old stack to >> BSPs >> that currently support it -- perhaps move it to a separate build tree. And >> more seriously consider LWIP. >> >> An even when an architecture has the infrastructure, there is at least the >> SPARC which I don't think have any Nexus devices >> <https://maps.google.com/?q=ich+I+don't+think+have+any+Nexus+devices&entry=gmail&source=g> >> or drivers for libbsd. >> > > The generic nexus device which works well on SPARC. We used the libbsd on > a SPARC project. And how would one know that except by the accident of this thread. Is network supported? I didn't see the greth in the three. > > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
