Standalone repository for libnetworking stack

Vijay Kumar Banerjee vijay at rtems.org
Fri Feb 26 17:58:45 UTC 2021 

On Fri, Feb 26, 2021 at 10: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.
Great.

>
> >>>> 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.
>
Ok. Thanks.

> >>>> 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?
>
> >>>>>
> >>>>> 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.
>
Ok.

> >
> >>>> 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
> >

More information about the devel mailing list