Legacy networking stack removal
Joel Sherrill
joel at rtems.org
Wed Oct 7 15:59:28 UTC 2020
On Wed, Oct 7, 2020 at 10:12 AM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:
>
> On 07/10/2020 16:12, Joel Sherrill wrote:
> >
> >
> > On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault <dufault at hda.com
> > <mailto:dufault at hda.com>> wrote:
> >
> >
> >
> > > On Oct 7, 2020, at 01:43 , Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at 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 <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>
> > >>> <mailto:chrisj at rtems.org <mailto:chrisj at 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 at rtems.org <mailto:devel at 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.
>
Agreed.
For one, There are drivers for the legacy stack not in libbsd. The sparc
NIC drivers are in this bucket for sure. And then there is just the general
issue of gluing the layers together, etc.
> >
> >
> >
> > 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 ;-)
>
This is the one barrier that we can work on without much effort and it
is generally beneficial long term. And lower is good from multiple
viewpoints.
>
At this point, I don't know that we have a good feel for a recommendation
for minimum code and data space.
>
> >
> > 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.
>
Hopefully.
>
> >
> > 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 ;-)
>
LOL.. I'll always push back at breaking APIs but we are quite conservative
and it has put a software tax on the project. At one point, there was the
old
and new interrupt model and what was called new then doesn't look like
what is there now. That taught me never to name something new, old,
or future. :)
We deliberately keep BSPs and architectures until they actively cause a
problem.
Of the three original RTEMS BSPs, the last (mvme136) was finally removed
in 2015. It only made the list then because it didn't have a network
interface.
Someone had actually dusted one off to use not terribly long before that.
That
board was added in 1988.
It's hard to remove things. Age isn't sufficient to remove. The mvme162 is
quite
old and the first BSP Chris worked on around 1991. But it has a network
interface
and some of the EPICS labs still have 100s of them.
Because RTEMS is open source, we can't count paying customers and
kill when the number is low enough. We have to read the tea leaves and
purge. Reading tea leaves is hard.
We all know the legacy stack really has users. We have to manage this one
pretty well. Some can move to libbsd. Some may be able to move to Lwip.
Some may choose to use RTEMS 5 and obsolete the boards. Some may
want the old stack around longer for their old boards.
Most of those options require a user actively supporting a core developer.
I just want to lay the groundwork and outline the options. The legacy stack
should be just that and discouraged from use.
But someone will need it. That's the way embedded systems are. LOL
--joel
>
> 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201007/5c8be0fb/attachment-0001.html>
More information about the devel
mailing list