<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 10:12 AM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</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>
On 07/10/2020 16:12, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault <<a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a><br>
> <mailto:<a href="mailto:dufault@hda.com" target="_blank">dufault@hda.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
> > On Oct 7, 2020, at 01:43 , Sebastian Huber<br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
> <mailto:<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>><br>
> >>> <mailto:<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>
> >>> What is the life span of the legacy stack in rtems.git? I<br>
> 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<br>
> 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<br>
> possible? What's<br>
> >>> required?<br>
> >> I suggest we move it to a top level repo with the network demo<br>
> 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<br>
> 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<br>
> the change.<br>
> >> Users who still depend on this stack need to either post here and<br>
> 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.<br>
> 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> <mailto:<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<br>
> evaluating but I couldn't always use the "libbsd" stack and made it<br>
> conditional.<br>
> <br>
> <br>
> The footprint is an issue but even on boards with enough memory, there<br>
> will be effort required to move to the new stack. <br></blockquote><div><br></div><div>Agreed. </div><div><br></div><div>For one, There are drivers for the legacy stack not in libbsd. The sparc </div><div>NIC drivers are in this bucket for sure. And then there is just the general</div><div>issue of gluing the layers together, etc. </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>
> <br>
> <br>
> I didn't spend much time trying to reduce the footprint. Maybe if<br>
> I'd removed some of the shell commands it would have been smaller.<br>
> <br>
> <br>
> It would be interesting to see what the smallest application that has<br>
> libbsd TCP/IP IPV4 in it could be. The old stack has a netdemo with a<br>
> couple of echo tasks which could come in around 250-300K code space. And<br>
> usually you didn't need a huge amount of buffers but the interfaces were<br>
> usually much slower. Even 100BaseT can require a lot of memory for<br>
> buffering. <br>
<br>
Note that you can reduce the footprint a bit by using the minimal<br>
buildset. It throws out stuff like IPv6 (who needs such modern stuff<br>
anyway?). But you will currently not reach the old stack. Maybe we<br>
should work towards throwing out more stuff out of the minimal buildset<br>
to make it smaller ;-)<br></blockquote><div><br></div><div>This is the one barrier that we can work on without much effort and it</div><div>is generally beneficial long term. And lower is good from multiple </div><div>viewpoints. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div><br></div><div>At this point, I don't know that we have a good feel for a recommendation</div><div>for minimum code and data space. </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>
> I recall adding a way to tune the default buffering per socket because I<br>
> helped with an app where it required about 1MB per socket by default.<br>
> <br>
> The old stack is just that old -- it was optimized for older hardware --<br>
> but it hasn't kept up with any potential fixes and as Chris pointed out<br>
> there is now a known issue against Windows. I'd like to encourage people<br>
> to move but unfortunately know some may want to do the risk calculation<br>
> and keep using it. <br>
> <br>
> Chris and I chatted about this. We thought removing it from rtems proper<br>
> and just creating another repo with just the files removed in their<br>
> current layout is the minimum legwork to make it possible to revive it<br>
> if someone asks. But we wouldn't touch it more unless someone REALLY<br>
> wants it revived.<br>
><br>
> <br>
> An alternative is "lwIP". I don't have experience with that. Maybe<br>
> "lwIP" and "libbsd" should be the recommended solutions.<br>
> <br>
> <br>
> lwIP may be a good option for many but it still leaves you with a driver<br>
> issue. It does solve the low memory issue and hopefully has enough<br>
> features for the applications on lower end hardware.<br>
<br>
Maybe the next time someone has a funded project into the direction of<br>
lwIP we should try to create a package repo so it can be build without a<br>
lot of effort.<br></blockquote><div><br></div><div>Hopefully. </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>
> Unfortunately, this is a case where the RTEMS core developers are too<br>
> nice. We don't want to leave users wanting. Many projects would have<br>
> killed the old stack before now. And I think it is long overdue for us. :)<br>
<br>
Do you ask us to be a bit less nice to users? I'll have to create a link<br>
so that I can reference this statement the next time we discuss a change<br>
that could break something for users ;-)<br></blockquote><div><br></div><div>LOL.. I'll always push back at breaking APIs but we are quite conservative</div><div>and it has put a software tax on the project. At one point, there was the old</div><div>and new interrupt model and what was called new then doesn't look like</div><div>what is there now. That taught me never to name something new, old,</div><div>or future. :)</div><div><br></div><div>We deliberately keep BSPs and architectures until they actively cause a problem.</div><div>Of the three original RTEMS BSPs, the last (mvme136) was finally removed </div><div>in 2015. It only made the list then because it didn't have a network interface.</div><div>Someone had actually dusted one off to use not terribly long before that. That</div><div>board was added in 1988. </div><div><br></div><div>It's hard to remove things. Age isn't sufficient to remove. The mvme162 is quite</div><div>old and the first BSP Chris worked on around 1991. But it has a network interface</div><div>and some of the EPICS labs still have 100s of them. </div><div><br></div><div>Because RTEMS is open source, we can't count paying customers and </div><div>kill when the number is low enough. We have to read the tea leaves and</div><div>purge. Reading tea leaves is hard. </div><div><br></div><div>We all know the legacy stack really has users. We have to manage this one</div><div>pretty well. Some can move to libbsd. Some may be able to move to Lwip.</div><div>Some may choose to use RTEMS 5 and obsolete the boards. Some may </div><div>want the old stack around longer for their old boards.</div><div><br></div><div>Most of those options require a user actively supporting a core developer.</div><div>I just want to lay the groundwork and outline the options. The legacy stack</div><div>should be just that and discouraged from use. </div><div><br></div><div>But someone will need it. That's the way embedded systems are. LOL</div><div><br></div><div>--joel</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>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> I am thinking 4-6 weeks after the transition from autoconf to waf, the<br>
> stack should come out. With any luck, this will be in December. Moving<br>
> to waf is an ideal time to clean cruft and being just after the 5<br>
> release, we left things in for that last release if that's what the<br>
> outcome is.<br>
> <br>
> --joel<br>
> <br>
> <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<br>
> subject to interception and tampering.<br>
> <br>
> <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>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>