Standalone repository for libnetworking stack

Joel Sherrill joel at rtems.org
Mon Mar 1 19:19:44 UTC 2021 

On Mon, Mar 1, 2021 at 1:05 PM Gedare Bloom <gedare at rtems.org> wrote:

> 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


This looks good. If it can easily be moved to the bottom of the list of
docs, that would be great.


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

+1 It is what is always has been.

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

To be completely above board and proper, I think so. please post to
both devel@ and users@ that your repo needs testing and that the
legacy stack is soon to be removed from the main rtems.git.

And make it VERY clear that anyone who plans to test, please
speak up. We can't demand they do it immediately but it would
be helpful to know someone is going to do it.

Which NIC did you test the PC with?


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

More information about the devel mailing list