<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 5, 2021, 5:17 PM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org">vijay@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Christian, Joel, Chris,<br>
<br>
On Fri, Feb 5, 2021 at 3:41 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
><br>
> 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" rel="noreferrer">oss@c-mauderer.de</a><br>
> > <mailto:<a href="mailto:oss@c-mauderer.de" target="_blank" rel="noreferrer">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 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>
I do have some repos in my area in <a href="http://dispatch.rtems.org" rel="noreferrer noreferrer" target="_blank">dispatch.rtems.org</a> but for some<br>
reason they don't appear in <a href="http://git.rtems.org" rel="noreferrer noreferrer" target="_blank">git.rtems.org</a> page that's why I pushed it<br>
in github. Am I possibly missing some step?<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>
That's a good point!<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>
rtems-net-legacy sounds right, I'll rename.<br>
<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>
><br>
Currently it builds for all BSPs, like libbsd.<br>
<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>
><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>
Understood. I'm not sure if they're used with libbsd but I think<br>
they're not as they're only built with RTEMS_NETWORKING enabled. I'll<br>
move them to the new repo.<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>
<br>
Ok.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Simple rule. If in libbsd and cpukit, move cpukit version to legacy. If only in cpukit, it is supposed to work on both.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> >     > 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>
Ok.<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>
I think I missed it while checking for the include paths in waf, I can<br>
check it again. If it works out, then I guess my question is already<br>
solved.<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>
Ok.<br>
> > Move those files so either stack can use them.<br>
> ><br>
This point is not clear to me. Do I add a copy of them in the network stack ?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No. Move them to libfs so either stack can use them. They should be independent. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > I'm thrilled to see this happening.<br>
><br>
> I am as well. Vijay thank you for taking on the task.<br>
><br>
:)<br>
> Chris<br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>