Some problems with the libbsd update

[Sebastian Huber]

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.

> + 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.

>
>
>     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 or drivers for libbsd.

The generic nexus device which works well on SPARC. We used the libbsd 
on a SPARC project.

-- 
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.