Standalone repository for libnetworking stack

Joel Sherrill joel at rtems.org
Fri Feb 26 19:30:08 UTC 2021 

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210226/4a3f36b1/attachment-0001.html>

More information about the devel mailing list