Standalone repository for libnetworking stack

Wed Mar 10 01:57:52 UTC 2021

On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <vijay at rtems.org> wrote:

> Hello,
>
> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> >
> > On Fri, Mar 5, 2021 at 9:37 AM Joel Sherrill <joel at rtems.org> wrote:
> > >
> > >
> > >
> > > On Fri, Mar 5, 2021 at 9:48 AM Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> If no one has any objections, I would like to push the RTEMS patches
> to remove libnetworking.
> > >>
> > >> The patches are in this repo:
> > >> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet
> > >
>
> Hi,
>
> In this proposed set of patches, I have removed telnetd from RTEMS and
> have placed it in the net-legacy repo, it seems like libbsd uses
> telnetd as well. Do we want to keep it in RTEMS and remove it from the
> legacy net repo?  There are checks in for RTEMS_NETWORKING in telnetd,
> to add rtems_bsdnet.h, how do we want to deal with that? In the legacy
> repo, we can just remove these checks and let them build.
>

Move it and remove rtems networking conditional. Freezes it with legacy
stack.

Just my opinion

--joel

> Best regards,
> Vijay
>
> > >
> > > I do not object but this is an impactful thing to do and it would
> > > be my preference to get concurrence from multiple core
> > > developers.
> > >
> > Thanks for reviewing! I'll wait for some more comments from other core
> > developers before pushing.
> >
> > Best regards,
> > Vijay
> > > --joel
> > >>
> > >>
> > >>
> > >>
> > >> Best regards,
> > >> Vijay
> > >>
> > >>
> > >> On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee <vijay at rtems.org>
> wrote:
> > >>>
> > >>> On Mon, Mar 1, 2021 at 1:24 PM Gedare Bloom <gedare at rtems.org>
> wrote:
> > >>> >
> > >>> > On Mon, Mar 1, 2021 at 1:16 PM Vijay Kumar Banerjee <
> vijay at rtems.org> wrote:
> > >>> > >
> > >>> > > On Mon, Mar 1, 2021 at 12:20 PM Joel Sherrill <joel at rtems.org>
> wrote:
> > >>> > > >
> > >>> > > >
> > >>> > > >
> > >>> > > > 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.
> > >>> > > >
> > >>> > > Great. I'll check it and create a patch for it (Assuming it can
> be
> > >>> > > done from the docs and doesn't need anything to be done from the
> > >>> > > website front end).
> > >>> > > >>
> > >>> > > >>
> > >>> > > >> >
> > >>> > > >> > 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.
> > >>> > > Great, I'll add a section in the README file.
> > >>> > >
> > >>> > > Regarding the README file in general: Is the current text
> suitable or
> > >>> > > should we add some information like this is the separate rtems
> legacy
> > >>> > > networking stack etc. ?
> > >>> > >
> > >>> >
> > >>> > Add a brief note, and identify where further  guidance is located
> > >>> > (README.waf, docs.rtems.org) and keep the historical stuff I
> suppose,
> > >>> > but provide a segue to it.
> > >>> >
> > >>> Thanks, I added it. I'll soon post an announcement to the devel (and
> > >>> users) about the separate repo, requesting testing from concerned
> > >>> users.
> > >>>
> > >>> > > >>
> > >>> > > >>
> > >>> > > >> 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.
> > >>> > > >
> > >>> > > Sure, I'll post in user and devel.
> > >>> > >
> > >>> > > > Which NIC did you test the PC with?
> > >>> > > >
> > >>> > >
> > >>> > > virtio
> > >>> > >
> > >>> > > >>
> > >>> > > >>
> > >>> > > >> > 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/20210309/8e69807a/attachment-0001.html>