On 07/10/2020 16:12, Joel Sherrill wrote: > > > On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault <dufa...@hda.com > <mailto:dufa...@hda.com>> wrote: > > > > > On Oct 7, 2020, at 01:43 , Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> wrote: > > > > On 07/10/2020 02:07, Chris Johns wrote: > > > >> On 7/10/20 10:21 am, Joel Sherrill wrote: > >>> On Tue, Oct 6, 2020, 6:16 PM Chris Johns <chr...@rtems.org > <mailto:chr...@rtems.org> > >>> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: > >>> > >>> What is the life span of the legacy stack in rtems.git? I > see this software as a > >>> liability. > >>> > >>> I'd love it to be a sliver over autoconf. > >> Sounds like a plan. I have created a task against the 6.1 milestone: > >> > >> https://devel.rtems.org/ticket/4126 > >> > >>> I think it is hard to actively encourage our users to use > libbsd if we have an > >>> enable or waf equivalent at hand in rtems.git. > >>> > >>> I'd love it to go in its own separate repo. Is that at all > possible? What's > >>> required? > >> I suggest we move it to a top level repo with the network demo > code and then see > >> what happens. In theory it should be easy to build with rtems_waf. > >> > >> The remaining fragments of code can be removed from the BSP files > and maybe > >> moved to a header file in the new repo once we have made the split. > >> > >> The change will break existing users but I think we need to make > the change. > >> Users who still depend on this stack need to either post here and > make us aware, > >> post fixes or directly contact you, me or others for support options. > > 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. > > _______________________________________________ > > devel mailing list > > devel@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > 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. > > > The footprint is an issue but even on boards with enough memory, there > will be effort required to move to the new stack. > > > > 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. > > > 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.
Note that you can reduce the footprint a bit by using the minimal buildset. It throws out stuff like IPv6 (who needs such modern stuff anyway?). But you will currently not reach the old stack. Maybe we should work towards throwing out more stuff out of the minimal buildset to make it smaller ;-) > > 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. > > 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. > > 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. > > > An alternative is "lwIP". I don't have experience with that. Maybe > "lwIP" and "libbsd" should be the recommended solutions. > > > 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. Maybe the next time someone has a funded project into the direction of lwIP we should try to create a package repo so it can be build without a lot of effort. > > 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. :) Do you ask us to be a bit less nice to users? I'll have to create a link so that I can reference this statement the next time we discuss a change that could break something for users ;-) Best regards Christian > > 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. > > --joel > > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > > This email is delivered through the public internet using protocols > subject to interception and tampering. > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 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
