Some problems with the libbsd update

[Joel Sherrill]

On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <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>> 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
+ 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.

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?



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




>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180822/60261d73/attachment-0002.html>