<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 22, 2018 at 6:00 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</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"><span class="gmail-">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">sebastian.huber@embedded-<wbr>brains.de</a><br>
>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@<wbr>embedded-brains.de</a>>> wrote:<br>
>><br>
</span><span class="gmail-">>> 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 matter.<br>
> <br>
> If the niche architectures don't use libbsd (which I guess is the case), then<br>
> there is no issue at all.<br>
> <br>
<br>
</span>Do we document what is supported and what is not supported?<br></blockquote><div><br></div><div>This was largely the point of my response. We don't have a master list of</div><div>at least the following information:</div><div><br></div><div>+ Architectures that support SMP and tested to N cores</div><div>+ Architectures that support TLS</div><div>+ Architectures that support libbsd</div><div><br></div><div>A user can't determine what is usable to them in for at least those</div><div>features. We need a basic feature table of at least the above</div><div>for users.</div><div><br></div><div>Beyond that, I would consider TLS a hidden basic feature since I think</div><div>we now rely on it in some infrastructure pieces (language run-times?).</div><div>We don't have ticket(s) related to which architectures need it added.</div><div>And no notes on how to extract the details on what to do from GCC.</div><div>I randomly checked gcc for the nios2 and guess that this is the</div><div>register:</div><div><br></div><div><div> (TP_REGNO 23) ; Thread pointer register</div></div><div><br></div><div>How I am supposed to figure that out reliably, I am not sure.</div><div><br></div><div>I checked the bfin and don't get any hits for tls/TLS or THREAD_LOCAL.</div><div>Perhaps it doesn't support it at all. Who knows?</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">
<br>
Does libbsd have suitable checks on the built RTEMS to know it cannot be supported?<br></blockquote><div><br></div><div>Without the above table, I am not sure how. Curious to hear Sebastian's answer.</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">
<br>
FWIW I do not think the idea of "one size fits all" is workable. I think a<br>
number of architectures would benefit from a different smaller networking stack.<br></blockquote><div><br></div><div>+1 </div><div><br></div><div>We are in a position where we need begin to deprecate the old stack to BSPs</div><div>that currently support it -- perhaps move it to a separate build tree. And </div><div>more seriously consider LWIP.</div><div><br></div><div>An even when an architecture has the infrastructure, there is at least the</div><div>SPARC which I don't think have any Nexus devices or drivers for libbsd.</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-HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>