Legacy networking stack removal

[Peter Dufault]

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

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.

An alternative is "lwIP".  I don't have experience with that.  Maybe "lwIP" and "libbsd" should be the recommended solutions.

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201007/ad3bb059/attachment-0001.bin>