On Fri, Feb 26, 2021 at 10:46 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Fri, Feb 26, 2021, 11:40 AM Vijay Kumar Banerjee <vi...@rtems.org> 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. > > > 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.
Sorry for the confusion. I meant checked. > > >> >> > This is awesome work and much appreciated. >> > >> Thank you. :) > > > You are welcome. >> >> >> > 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. >> >> >> > 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@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