Some problems with the libbsd update

Thu Aug 23 13:40:36 UTC 2018

On Thu, Aug 23, 2018 at 12:15 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 23/08/18 01:13, Joel Sherrill wrote:
>
>>
>>
>> On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <chrisj at rtems.org <mailto:
>> chrisj at 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.huber at embedded-brains.de
>>     <mailto:sebastian.huber at embedded-brains.de>
>>     >> <mailto:sebastian.huber at embedded-brains.de
>>     <mailto:sebastian.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180823/8a2e1704/attachment-0002.html>