Standalone repository for libnetworking stack

Mon Mar 1 19:05:07 UTC 2021

On Mon, Mar 1, 2021 at 11:28 AM Vijay Kumar Banerjee <vijay at rtems.org> wrote:
>
> Hi,
>
> I have shifted the testsuites and have checked that all the tests run successfully with pc-qemu. I have also updated the README.waf as per the review and have fixed formatting according to PEP8. Please review the repos and let me know if there's something else that needs to be improved to make it mergeable.
> RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> rtems-net-legacy: https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
>
> I have also made a patch for rtems-docs to rename networking to legacy networking:
> https://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a
>
> I haven't added any LICENSE file as I really didn't understand what we can put in there. I can add the RTEMS LICENSE file from https://www.rtems.org/license/LICENSE as it was discussed in the list before. Please let me know what is desirable.
>
I don't think we should have a LICENSE file, instead I think there
should be a section of the README that discusses the licensing
situation.

The code is licensed under a mix of the rtems.org/LICENSE and various
BSD licenses. That is all that needs to be said, if anything.

Do we need to put out a call for anyone to step up to deal with
anything in BSPs?

> Best regards,
> Vijay
>
> On Fri, Feb 26, 2021 at 12:30 PM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Fri, Feb 26, 2021, 11:49 AM Chris Johns <chrisj at rtems.org> wrote:
> >>
> >> On 27/2/21 4:40 am, Vijay Kumar Banerjee wrote:
> >> > Hi all,
> >> >
> >> > Thanks for reviewing
> >> >
> >> > On Fri, Feb 26, 2021 at 10:13 AM Joel Sherrill <joel at rtems.org> wrote:
> >> >>
> >> >> Some odd questions that are mostly about making this a self-contained entity with no loose ends.
> >> >>
> >> >> + Can the network demos be merged also?
> >> >>
> >> > Are we talking about testsuites tests that use legacy networking? If
> >> > so, then I have already shifted the networking01.exe and will shift
> >> > other tests using the same approach.
> >> >
> >> >> + rtems-docs has the Network Users Guide which is legacy only. As a minimum, it needs to be renamed to have Legacy in the title. Better would be to convert it to markdown/asciidoc and just toss it in the legacy repo.
> >> >>
> >> > This is a good point! I'll probably just keep it as a README in the
> >> > net-legacy repo.
> >> >
> >> >> + Gaisler needs a poke about the grlib NIC drivers. And Daniel expects it. File a ticket that it is time for them to support libbsd and assign it to him. :)
> >> >>
> >> >> I'm ok with Chris' proposal to give notice  Grep'ing for NETWORK_DRIVER_NAME did turn up more files than I expected. Perhaps that is simply a list of driver names and attach functions for a readme in the repo. That's all that should have been in the bsp.h files.
> >> >>
> >> > Yes, these are mostly bsp.h files. I'll file a ticket and post to
> >> > users and devel about it. There are also quite a few with
> >> > RTEMS_NETWORKING defined.
> >> >
> >> >> This is awesome work and much appreciated.
> >> >>
> >> > Thank you. :)
> >> >
> >> >> On Fri, Feb 26, 2021 at 12:12 AM Gedare Bloom <gedare at rtems.org> wrote:
> >> >>>
> >> >>> On Thu, Feb 25, 2021 at 6:06 PM Chris Johns <chrisj at rtems.org> wrote:
> >> >>>>
> >> >>>> On 26/2/21 4:49 am, Vijay Kumar Banerjee wrote:
> >> >>>>> The stand-alone repository is very close to completion now and I could
> >> >>>>> use the networking01 test with the standalone repo and it successfully
> >> >>>>> runs on pc-qemu.
> >> >>>>
> >> >>>> Fantastic news.
> >> >>>>
> >> >>>>> The following are the links to the branches with the
> >> >>>>> final version of the commits and I would really appreciate a review
> >> >>>>> and suggestions on what else needs to be done (I'm not sending patches
> >> >>>>> as they're big and would hit the devel limit):
> >> >>>>
> >> >>>> I am fine reviewing the changes in the repos.
> >> >>>>
> >> >>>>> RTEMS: https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> >> >>>>
> >> >>>> Looks good. The only observation is a bisect will probability break as the
> >> >>>> nfsclient depends on rpc but I am OK with now things are.
> >> >>>>
> >> >>>> I checked rtems_waf and I think it is OK dealing with no networking defined in
> >> >>>> the RTEMS opts header.
> >> >>>>
> >> > Great!
> >> >
> >> >>>>> rtems-net-legacy: https://git.rtems.org/vijay/rtems-net-legacy.git/log/?h=main
> >> >>>>
> >> >>>> Would calling lnetwork.py netlegacy.py be a better match for that name? Closer
> >> >>>> to the repo naming.
> >> >>>>
> >> > Sure, I'll rename it and force push.
> >>
> >> Thanks
> >>
> >> >
> >> >>>> Do the new python files need to pep8 formatted? :)
> >> >>>> [ https://gitlab.com/ita1024/waf/-/tree/master/playground/pep8 ]
> >> >>>>
> >> > pep8 does work for me when used manually but with waf module I'm
> >> > getting the following error:
> >> >
> >> > ```
> >> >   File "/home/vijay/.local/lib/python3.8/site-packages/pep8.py", line
> >> > 253, in maximum_line_length
> >> >     if length > options.max_line_length:
> >> > AttributeError: 'Values' object has no attribute 'max_line_length'
> >> > ```
> >> > This is strange because it looks like an error in the pep8 module itself.
> >> >
> >> > I have tried different versions of pep8 and it looks like each version
> >> > has a different error. I think this needs some work from the waf side
> >> > to get it working with the new pycodestyle instead of the pep8 module.
> >>
> >> Running manually is fine.
> >>
> >> >>>> In bsp_drivers.py is there a waf node way to find the sources rather than
> >> >>>> python os walk?
> >> >>>> [ https://waf.io/apidocs/Node.html#waflib.Node.Node.ant_glob ]
> >> >>>>
> >> > I gave it a few shots but it didn't quite work out well for me.  I do
> >> > get the generator from it but for some reason, it's not building. We
> >> > would also need the list of headers for the install, for which I think
> >> > os.walk might be needed.
> >> >
> >> > Is this a blocker to merging? If so, then I can put more time into it
> >> > and try to get it working. If you want it as an optimization, maybe we
> >> > could merge it and file a ticket? I can take more time and fix it
> >> > later.
> >>
> >> Thanks for looking, the os.walk is fine.
> >>
> >> >>>> Should the README reference rtems_waf and all the configure options it supports?
> >> >>>>
> >> > This is a good point, The README needs some update for sure. I'll
> >> > follow the README.waf from other repos and follow the same pattern.
> >> >
> >> >>>> Do we need a LICENSE file?
> >> >>>>
> >> > Do we?
> >>
> >> I think it helps but I am not sure what it would contain. Joel?
> >
> >
> > It would be hard to have a completely accurate one if it has to account for every BSD file with unique copyright holders a d two vs three paragraph license
> >
> > Perhaps descriptive contents that says it contains code under multiple permissive licenses. See the specific files for details.
> >
> > It's good to have one but not worth the effort to do more than that.
> >
> >>
> >> >>>>>
> >> >>>>> There are at least two things that need to be done:
> >> >>>>> 1. Shift the tests like mghttpd01 that use the libnetworking stack, to
> >> >>>>> the standalone repo like networking01
> >> >>>>
> >> >>>> OK
> >> > I'll do it along with the README and send it for review.
> >>
> >> Thanks
> >>
> >> >>>>
> >> >>>>> 2. There are still codes that use the #ifdef RTEMS_NETWORKING. What do
> >> >>>>> we want to do about those?
> >> >>>>
> >> >>>> How many BSPs/places/areas are we talking about?
> >> >>>>
> >> >>>> Would it be practical to add a cgit link to a ticket and then post an email to
> >> >>>> user and devel stating those interested in BSPs x,y,z to review the ticket? We
> >> >>>> then wait a week and after that the remaining defines are removed.
> >> >>>>
> >> >
> >> > grep shows this:
> >> > ```
> >> > cpukit/libfs/src/ftpfs/tftpDriver.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/libfs/src/ftpfs/tftpDriver.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/libfs/src/ftpfs/tftpDriver.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/libfs/src/ftpfs/tftpDriver.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/telnetd/telnetd.c:#ifdef RTEMS_NETWORKING
> >> > cpukit/ftpd/ftpd.c:#ifndef RTEMS_NETWORKING
> >> > cpukit/libtest/testbeginend.c:#if RTEMS_NETWORKING
> >> > cpukit/libtest/testbeginend.c:    " RTEMS_NETWORKING"
> >> > cpukit/include/rtems/monitor.h:#if defined(RTEMS_NETWORKING)
> >> > cpukit/include/rtems/shellconfig.h:#if RTEMS_NETWORKING
> >> > cpukit/include/rtems/shellconfig.h:    #if RTEMS_NETWORKING
> >> > spec/build/testsuites/samples/pppd.yml:  - RTEMS_NETWORKING
> >> > spec/build/testsuites/samples/loopback.yml:- RTEMS_NETWORKING
> >> > spec/build/testsuites/libtests/telnetd01.yml:- RTEMS_NETWORKING
> >> > spec/build/testsuites/libtests/mghttpd01.yml:  - RTEMS_NETWORKING
> >> > spec/build/testsuites/libtests/syscall01.yml:- RTEMS_NETWORKING
> >> > spec/build/testsuites/libtests/networking01.yml:- RTEMS_NETWORKING
> >> > spec/build/testsuites/libtests/ftp01.yml:- RTEMS_NETWORKING
> >> > spec/build/bsps/powerpc/motorola_powerpc/objqemunet.yml:  - RTEMS_NETWORKING
> >> > spec/build/bsps/objnetnosmp.yml:  - RTEMS_NETWORKING
> >> > spec/build/bsps/riscv/griscv/objnetnosmp.yml:  - RTEMS_NETWORKING
> >> > testsuites/libtests/record01/init.c:#ifdef RTEMS_NETWORKING
> >> > testsuites/libtests/record01/init.c:#ifdef RTEMS_NETWORKING
> >> > testsuites/libtests/record01/init.c:#ifdef RTEMS_NETWORKING
> >> > testsuites/libtests/record01/init.c:#ifdef RTEMS_NETWORKING
> >> > bsps/powerpc/beatnik/include/bsp.h:#if defined(RTEMS_NETWORKING)
> >> > bsps/lm32/milkymist/include/bsp.h:#if defined(RTEMS_NETWORKING)
> >> > bsps/lm32/lm32_evr/include/bsp.h:#if defined(RTEMS_NETWORKING)
> >> >
> >> > ```
> >> > I can already see a small issue from my side. The networking01.yml is
> >> > there. That will go away, along with some other testsuites yml that
> >> > I'll shift now. Do we need ticket for the rest?
> >>
> >> A single ticket for this task is fine.
> >
> >
> > I would say we always build with networking in in the future. The standard headers are there always.
> >
> > Perhaps ones in telnetd and similar can go away if that decision is made versus saying it disables common network services.
> >>
> >>
> >> >
> >> >>>> Do we have a ticket for this task?
> >> >>>>
> >> >>> https://devel.rtems.org/ticket/3850
> >> >>>
> >> > Thanks.
> >>
> >> Thanks.
> >>
> >> Chris
> >>
> >> >
> >> >>> I'll let Vijay answer the rest.
> >> >>>
> >> >>>>> Apart from these two points above, do the commits and the standalone
> >> >>>>> repo look OK (close to mergeable)?
> >> >>>>
> >> >>>> For me this is very close and a welcomed change for RTEMS 6. Really nice work.
> >> >>>>
> >> > Thank you!
> >> >
> >> > Best regards,
> >> > Vijay
> >> >
> >> >>>> Thanks
> >> >>>> Chris
> >> >>>> _______________________________________________
> >> >>>> devel mailing list
> >> >>>> devel at rtems.org
> >> >>>> http://lists.rtems.org/mailman/listinfo/devel
> >> >>> _______________________________________________
> >> >>> devel mailing list
> >> >>> devel at rtems.org
> >> >>> http://lists.rtems.org/mailman/listinfo/devel
> >> >>
> >> >> _______________________________________________
> >> >> devel mailing list
> >> >> devel at rtems.org
> >> >> http://lists.rtems.org/mailman/listinfo/devel
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
> >> >