Standalone repository for libnetworking stack

Vijay Kumar Banerjee vijay at rtems.org
Mon Mar 1 18:28:12 UTC 2021 

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
<https://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a>
.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a
<http://git.rtems.org/vijay/rtems-docs.git/commit/?id=92b53d211b4d9ad795ef8b2ad1ac0deed5a25f9a>

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.

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/b5193669/attachment-0001.html>

More information about the devel mailing list