<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Oct 7, 2020, at 01:43 , Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> <br>
> On 07/10/2020 02:07, Chris Johns wrote:<br>
> <br>
>> On 7/10/20 10:21 am, Joel Sherrill wrote:<br>
>>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
>>> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
>>> <br>
>>>     What is the life span of the legacy stack in rtems.git? I see this software as a<br>
>>>     liability.<br>
>>> <br>
>>> I'd love it to be a sliver over autoconf.<br>
>> Sounds like a plan. I have created a task against the 6.1 milestone:<br>
>> <br>
>> <a href="https://devel.rtems.org/ticket/4126" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/4126</a><br>
>> <br>
>>>     I think it is hard to actively encourage our users to use libbsd if we have an<br>
>>>     enable or waf equivalent at hand in rtems.git.<br>
>>> <br>
>>> I'd love it to go in its own separate repo. Is that at all possible? What's<br>
>>> required?<br>
>> I suggest we move it to a top level repo with the network demo code and then see<br>
>> what happens. In theory it should be easy to build with rtems_waf.<br>
>> <br>
>> The remaining fragments of code can be removed from the BSP files and maybe<br>
>> moved to a header file in the new repo once we have made the split.<br>
>> <br>
>> The change will break existing users but I think we need to make the change.<br>
>> Users who still depend on this stack need to either post here and make us aware,<br>
>> post fixes or directly contact you, me or others for support options.<br>
> Maintaining or removing the old network stack is both fine for me. Moving the stuff out of the RTEMS repository is a bit of work.<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
<br>
The footprint is larger.  I forget exactly which board I was evaluating but I couldn't always use the "libbsd" stack and made it conditional.<br></blockquote><div><br></div><div>The footprint is an issue but even on boards with enough memory, there will be effort required to move to the new stack. </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>
I didn't spend much time trying to reduce the footprint.  Maybe if I'd removed some of the shell commands it would have been smaller.<br></blockquote><div><br></div><div>It would be interesting to see what the smallest application that has libbsd TCP/IP IPV4 in it could be. The old stack has a netdemo with a couple of echo tasks which could come in around 250-300K code space. And usually you didn't need a huge amount of buffers but the interfaces were usually much slower. Even 100BaseT can require a lot of memory for buffering. </div><div><br></div><div>I recall adding a way to tune the default buffering per socket because I helped with an app where it required about 1MB per socket by default.</div><div><br></div><div>The old stack is just that old -- it was optimized for older hardware -- but it hasn't kept up with any potential fixes and as Chris pointed out there is now a known issue against Windows. I'd like to encourage people to move but unfortunately know some may want to do the risk calculation and keep using it. </div><div><br></div><div>Chris and I chatted about this. We thought removing it from rtems proper and just creating another repo with just the files removed in their current layout is the minimum legwork to make it possible to revive it if someone asks. But we wouldn't touch it more unless someone REALLY wants it revived.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
An alternative is "lwIP".  I don't have experience with that.  Maybe "lwIP" and "libbsd" should be the recommended solutions.<br></blockquote><div><br></div><div>lwIP may be a good option for many but it still leaves you with a driver issue. It does solve the low memory issue and hopefully has enough features for the applications on lower end hardware.</div><div><br></div><div>Unfortunately, this is a case where the RTEMS core developers are too nice. We don't want to leave users wanting. Many projects would have killed the old stack before now.  And I think it is long overdue for us. :)</div><div><br></div><div>I am thinking 4-6 weeks after the transition from autoconf to waf, the stack should come out. With any luck, this will be in December.  Moving to waf is an ideal time to clean cruft and being just after the 5 release, we left things in for that last release if that's what the outcome is.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc.      Software and System Engineering<br>
<br>
This email is delivered through the public internet using protocols subject to interception and tampering.<br>
<br>
</blockquote></div></div>