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