Legacy networking stack removal

[Joel Sherrill]

On Wed, Oct 7, 2020 at 6:30 AM Peter Dufault <dufault at hda.com> wrote:

>
>
> > On Oct 7, 2020, at 01:43 , Sebastian Huber <
> 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>> 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
> > 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.

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.

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. :)

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201007/091b82a6/attachment.html>