Legacy networking stack removal
dufault at hda.com
Wed Oct 7 11:29:55 UTC 2020
> 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
>>> I'd love it to be a sliver over autoconf.
>> Sounds like a plan. I have created a task against the 6.1 milestone:
>>> 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
>> 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
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.
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...
Size: 235 bytes
Desc: Message signed with OpenPGP
More information about the devel