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