Legacy networking stack removal

[Sebastian Huber]

On 07/10/2020 13:29, Peter Dufault 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.
>
> 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.
Yes, the libbsd footprint is considerably larger. It has also a lot of 
features. For the low-end endpoint devices lwIP is probably the better 
choice.