<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 4:41 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</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">On 6/2/21 8:28 am, Joel Sherrill wrote:<br>
> On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a><br>
> <mailto:<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>>> wrote:<br>
> <br>
>     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>
If you have not already done so I suggest you create repos in your personal area<br>
on <a href="http://dispatch.rtems.org" rel="noreferrer" target="_blank">dispatch.rtems.org</a> and these will appear on the cgit page. It is a simple way<br>
to get exposure to the work.<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>
> <br>
> <br>
> We could make it painful and obvious using something like <br>
> rtems-legacy-networking :) <br>
<br>
.. or rtems-net-legacy ... small, clear and simple.<br>
<br>
> I assume you are also taking all legacy network drivers with you.<br>
<br>
Yes this is a good point. They will have to move as well. I hope this does not<br>
create links back into BSP specific headers that are not currently being installed.<br>
<br>
> One random thought is whether this should only build for specific BSPs. We<br>
> currently can build the stack for nearly all architectures but I don't think that<br>
> realistically there are BSPs which run it on all architectures. Should there be<br>
> a whitelist of supported BSPs?<br>
<br>
There are BSPs where the drivers are not in RTEMS because of chip vendor<br>
licensing issues. Why not follow the rtems-libbsd model?<br></blockquote><div><br></div><div>And by this, what do you mean? Be able to build it even if there are no BSP</div><div>specific drivers available?</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>
> And I used "supported" quite loosely. I expect that other than a <br>
> small number of BSPs you can check on simulators, this is not going to<br>
> be heavily tested beyond building. This is not a criticism. I think it is<br>
> just a reality of doing something better than removing it entirely.<br>
<br>
If it is tested when split and then maintained so it builds it should stay in a<br>
reasonable state. We just need to state clearly our intentions and if someone<br>
really needs support there are commercial support options.<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>
> <br>
> I thought the point of having the network headers in newlib was to enable<br>
> user space networking applications that could build independent of the<br>
> network stack in use. I think these should stay in rtems/ as much as possible.<br>
<br>
Do we need to audit which pieces are generic networking applications and which<br>
are tied to libnetworking. For example libbsd has an NFS network client and so<br>
does the legacy stack.<br></blockquote><div><br></div><div>Probably. If they are in both, move the one in rtems/ to the legacy kit. </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>
> <br>
> Yes. This is how it is supposed to work and should with libbsd now. <br>
<br>
This is also my understanding.<br>
<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>
> <br>
> <br>
> +1 <br>
<br>
+1<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>
> <br>
> +1 <br>
<br>
+1<br>
<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>
> <br>
> Hmm... that appears to be used only by the tftp client filesystem. That should<br>
> be in libfs/src really.  There is also an ftp client filesystem which also needs to<br>
> move. They SHOULD work independent of the network stack.<br>
> <br>
> Move those files so either stack can use them.<br>
> <br>
> I'm thrilled to see this happening.<br>
<br>
I am as well. Vijay thank you for taking on the task.<br>
<br>
Chris<br>
</blockquote></div></div>