Standalone repository for libnetworking stack

Fri Feb 26 17:46:22 UTC 2021

On Fri, Feb 26, 2021, 11:40 AM Vijay Kumar Banerjee <vijay at rtems.org> 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.
>

No. This is a separate repository at RTEMS.org

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

+1

It is just confusing. I doubt there is anything that applies to libbsd.

But we also need a users guide for libbsd to at least cover the RTEMS
specific parts and help with common things. Not part of this task.

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

Defined or checked? I wonder what conditionals will be left.

> > This is awesome work and much appreciated.
> >
> Thank you. :)
>

You are welcome.

>
> > 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.
>
> >> > 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.
>
> >> > 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.
>
> >> > 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?
>
> >> > >
> >> > > 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.
>
> >> >
> >> > > 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?
>
> >> > Do we have a ticket for this task?
> >> >
> >> https://devel.rtems.org/ticket/3850
> >>
> Thanks.
>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210226/c220640e/attachment-0001.html>