On Fri, Feb 5, 2021, 5:17 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote:
> Hello Christian, Joel, Chris, > > On Fri, Feb 5, 2021 at 3:41 PM Chris Johns <chr...@rtems.org> wrote: > > > > On 6/2/21 8:28 am, Joel Sherrill wrote: > > > On Fri, Feb 5, 2021 at 2:54 PM Christian Mauderer <o...@c-mauderer.de > > > <mailto:o...@c-mauderer.de>> wrote: > > > > > > Hello Vijay, > > > > > > On 05/02/2021 19:41, Vijay Kumar Banerjee wrote: > > > > Hello, > > > > > > > > I'm currently working on separating the libnetworking stack into > its > > > > standalone repository that can be built separately with waf. The > current > > > > status of the project is that I have a working > rtems-libnetworking > > > > repository [1] that builds with waf (hasn't been tested with any > test > > > > cases yet). And In my fork of RTEMS I have separated the > libnetworking > > > > stack [2]. > > > > If you have not already done so I suggest you create repos in your > personal area > > on dispatch.rtems.org and these will appear on the cgit page. It is a > simple way > > to get exposure to the work. > > > I do have some repos in my area in dispatch.rtems.org but for some > reason they don't appear in git.rtems.org page that's why I pushed it > in github. Am I possibly missing some step? > > > > Sounds like an interesting work. If I didn't miss an earlier > discussion: > > > I think the name might could trigger one. It gives the impression > that > > > it is _the_ networking stack to use. But for newer BSPs most of > the time > > > libbsd is the better choice. > > > > That's a good point! > > > > > > > We could make it painful and obvious using something like > > > rtems-legacy-networking :) > > > > .. or rtems-net-legacy ... small, clear and simple. > > rtems-net-legacy sounds right, I'll rename. > > > > > > I assume you are also taking all legacy network drivers with you. > > > > Yes this is a good point. They will have to move as well. I hope this > does not > > create links back into BSP specific headers that are not currently being > installed. > > > > > One random thought is whether this should only build for specific > BSPs. We > > > currently can build the stack for nearly all architectures but I don't > think that > > > realistically there are BSPs which run it on all architectures. Should > there be > > > a whitelist of supported BSPs? > > > > There are BSPs where the drivers are not in RTEMS because of chip vendor > > licensing issues. Why not follow the rtems-libbsd model? > > > Currently it builds for all BSPs, like libbsd. > > > > And I used "supported" quite loosely. I expect that other than a > > > small number of BSPs you can check on simulators, this is not going to > > > be heavily tested beyond building. This is not a criticism. I think it > is > > > just a reality of doing something better than removing it entirely. > > > > If it is tested when split and then maintained so it builds it should > stay in a > > reasonable state. We just need to state clearly our intentions and if > someone > > really needs support there are commercial support options. > > > > > > I need suggestions with the following questions: > > > > > > > > 1. What to do with the codes in RTEMS outside the libnetworking > stack, > > > > which uses the networking library. Libraries for example libpppd > uses > > > > libnetworking. Do we want to shift these to the separate > repository for > > > > libnetworking or do we want to keep them in RTEMS and use the > waf system > > > > to selectively built those when the libnetworking is available in > > > > PREFIX. We can add a common header file that #defines > RTEMS_NETWORKING, > > > > so that the related codes can be built and used. > > > > > > I think it depends: > > > > > > Can they be used with libbsd or only with the legacy stack? > > > > > > I thought the point of having the network headers in newlib was to > enable > > > user space networking applications that could build independent of the > > > network stack in use. I think these should stay in rtems/ as much as > possible. > > > > Do we need to audit which pieces are generic networking applications and > which > > are tied to libnetworking. For example libbsd has an NFS network client > and so > > does the legacy stack. > > > > > If they can be used with libbsd: Can they be build without a > networking > > > stack? In that case it might would be possible to build them in > RTEMS > > > and link them later with either libbsd, with libnetworking or > (maybe) > > > some-when with lwIP. I don't think there is a reason to not build > them > > > for any BSP if they can be build without a networking stack. > > > > > > Yes. This is how it is supposed to work and should with libbsd now. > > > > This is also my understanding. > > Understood. I'm not sure if they're used with libbsd but I think > they're not as they're only built with RTEMS_NETWORKING enabled. I'll > move them to the new repo. > > > > > If they can't be used with libbsd (or another stack) I would > suggest to > > > keep them together with the legacy stack in your new libnetworking > > > repository. > > > > > > > > > +1 > > > > +1 > >. > > Ok. > Simple rule. If in libbsd and cpukit, move cpukit version to legacy. If only in cpukit, it is supposed to work on both. > > > 2. There are a few header files in cpukit/include that are > required by > > > > the libnetworking stack. Currently the rtems-libnetworking is > building > > > > in sort of a hackish way by using the header file from the RTEMS > source > > > > directory. Do we want to add these header files (like tftp.h) and > > > > related source files to the libnetworking directory? The other > way to > > > > use them would be to install the required headers in the PREFIX > and use > > > > them from libnetworking. > > > > > > If I understand correctly, the headers are not installed? In that > case: > > > Who else uses these headers? If no one except for the network stack > > > needs them: Move them to your new library. > > > > > > +1 > > > > +1 > Ok. > > > > > In case of the tftp.h: It seems that this file is installed, isn't > it? > > > So why can't you just use it from libnetworking? > > > > I think I missed it while checking for the include paths in waf, I can > check it again. If it works out, then I guess my question is already > solved. > > > > Hmm... that appears to be used only by the tftp client filesystem. > That should > > > be in libfs/src really. There is also an ftp client filesystem which > also needs to > > > move. They SHOULD work independent of the network stack. > > > > Ok. > > > Move those files so either stack can use them. > > > > This point is not clear to me. Do I add a copy of them in the network > stack ? > No. Move them to libfs so either stack can use them. They should be independent. > > > > I'm thrilled to see this happening. > > > > I am as well. Vijay thank you for taking on the task. > > > :) > > Chris > > _______________________________________________ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel