<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de">oss@c-mauderer.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Vijay,<br>
<br>
On 05/02/2021 19:41, Vijay Kumar Banerjee wrote:<br>
> Hello,<br>
> <br>
> I'm currently working on separating the libnetworking stack into its <br>
> standalone repository that can be built separately with waf. The current <br>
> status of the project is that I have a working rtems-libnetworking <br>
> repository [1] that builds with waf (hasn't been tested with any test <br>
> cases yet). And In my fork of RTEMS I have separated the libnetworking <br>
> stack [2].<br>
<br>
Sounds like an interesting work. If I didn't miss an earlier discussion: <br>
I think the name might could trigger one. It gives the impression that <br>
it is _the_ networking stack to use. But for newer BSPs most of the time <br>
libbsd is the better choice.<br></blockquote><div><br></div><div>We could make it painful and obvious using something like </div><div>rtems-legacy-networking :) </div><div><br></div><div>I assume you are also taking all legacy network drivers with you.</div><div><br></div><div>One random thought is whether this should only build for specific BSPs. We</div><div>currently can build the stack for nearly all architectures but I don't think that</div><div>realistically there are BSPs which run it on all architectures. Should there be</div><div>a whitelist of supported BSPs?</div><div><br></div><div>And I used "supported" quite loosely. I expect that other than a </div><div>small number of BSPs you can check on simulators, this is not going to</div><div>be heavily tested beyond building. This is not a criticism. I think it is</div><div>just a reality of doing something better than removing it entirely.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> I need suggestions with the following questions:<br>
> <br>
> 1. What to do with the codes in RTEMS outside the libnetworking stack, <br>
> which uses the networking library. Libraries for example libpppd uses <br>
> libnetworking. Do we want to shift these to the separate repository for <br>
> libnetworking or do we want to keep them in RTEMS and use the waf system <br>
> to selectively built those when the libnetworking is available in <br>
> PREFIX. We can add a common header file that #defines RTEMS_NETWORKING, <br>
> so that the related codes can be built and used.<br>
<br>
I think it depends:<br>
<br>
Can they be used with libbsd or only with the legacy stack?<br></blockquote><div><br></div><div>I thought the point of having the network headers in newlib was to enable</div><div>user space networking applications that could build independent of the</div><div>network stack in use. I think these should stay in rtems/ as much as possible.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If they can be used with libbsd: Can they be build without a networking <br>
stack? In that case it might would be possible to build them in RTEMS <br>
and link them later with either libbsd, with libnetworking or (maybe) <br>
some-when with lwIP. I don't think there is a reason to not build them <br>
for any BSP if they can be build without a networking stack.<br></blockquote><div><br></div><div>Yes. This is how it is supposed to work and should with libbsd now. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If they can't be used with libbsd (or another stack) I would suggest to <br>
keep them together with the legacy stack in your new libnetworking <br>
repository.<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> 2. There are a few header files in cpukit/include that are required by <br>
> the libnetworking stack. Currently the rtems-libnetworking is building <br>
> in sort of a hackish way by using the header file from the RTEMS source <br>
> directory. Do we want to add these header files (like tftp.h) and <br>
> related source files to the libnetworking directory? The other way to <br>
> use them would be to install the required headers in the PREFIX and use <br>
> them from libnetworking.<br>
<br>
If I understand correctly, the headers are not installed? In that case: <br>
Who else uses these headers? If no one except for the network stack <br>
needs them: Move them to your new library.<br></blockquote><div><br></div><div>+1 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In case of the tftp.h: It seems that this file is installed, isn't it? <br>
So why can't you just use it from libnetworking?<br></blockquote><div><br></div><div>Hmm... that appears to be used only by the tftp client filesystem. That should</div><div>be in libfs/src really.  There is also an ftp client filesystem which also needs to</div><div>move. They SHOULD work independent of the network stack.</div><div><br></div><div>Move those files so either stack can use them.</div><div><br></div><div>I'm thrilled to see this happening.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Any suggestions regarding these questions is greatly appreciated.<br>
> <br>
> <br>
> Best regards,<br>
> Vijay<br>
> <br>
> [1]: <a href="https://github.com/thelunatic/rtems-libnetworking" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems-libnetworking</a> <br>
> <<a href="https://github.com/thelunatic/rtems-libnetworking" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems-libnetworking</a>><br>
> [2]: <a href="https://github.com/thelunatic/rtems/tree/no-libnet" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems/tree/no-libnet</a> <br>
> <<a href="https://github.com/thelunatic/rtems/tree/no-libnet" rel="noreferrer" target="_blank">https://github.com/thelunatic/rtems/tree/no-libnet</a>><br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>