On Fri, Feb 26, 2021 at 10: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. Great.
> > >>>> 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. > Ok. Thanks. > >>>> 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? > > >>>>> > >>>>> 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. > Ok. > > > >>>> 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
