On Mon, Mar 1, 2021 at 11:28 AM Vijay Kumar Banerjee <vi...@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 > > 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. Do we need to put out a call for anyone to step up to deal with anything in BSPs? > Best regards, > Vijay > > On Fri, Feb 26, 2021 at 12:30 PM Joel Sherrill <j...@rtems.org> wrote: > > > > > > > > On Fri, Feb 26, 2021, 11:49 AM Chris Johns <chr...@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 <j...@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 <ged...@rtems.org> wrote: > >> >>> > >> >>> On Thu, Feb 25, 2021 at 6:06 PM Chris Johns <chr...@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@rtems.org > >> >>>> http://lists.rtems.org/mailman/listinfo/devel > >> >>> _______________________________________________ > >> >>> devel mailing list > >> >>> devel@rtems.org > >> >>> http://lists.rtems.org/mailman/listinfo/devel > >> >> > >> >> _______________________________________________ > >> >> devel mailing list > >> >> devel@rtems.org > >> >> http://lists.rtems.org/mailman/listinfo/devel > >> > _______________________________________________ > >> > devel mailing list > >> > devel@rtems.org > >> > http://lists.rtems.org/mailman/listinfo/devel > >> > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
