On Fri, Mar 5, 2021 at 9:37 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Fri, Mar 5, 2021 at 9:48 AM Vijay Kumar Banerjee <vi...@rtems.org> wrote: >> >> Hi all, >> >> If no one has any objections, I would like to push the RTEMS patches to >> remove libnetworking. >> >> The patches are in this repo: >> https://git.rtems.org/vijay/rtems.git/log/?h=devel-no-libnet > > > I do not object but this is an impactful thing to do and it would > be my preference to get concurrence from multiple core > developers. > Thanks for reviewing! I'll wait for some more comments from other core developers before pushing.
Best regards, Vijay > --joel >> >> >> >> >> Best regards, >> Vijay >> >> >> On Mon, Mar 1, 2021, 14:48 Vijay Kumar Banerjee <vi...@rtems.org> wrote: >>> >>> On Mon, Mar 1, 2021 at 1:24 PM Gedare Bloom <ged...@rtems.org> wrote: >>> > >>> > On Mon, Mar 1, 2021 at 1:16 PM Vijay Kumar Banerjee <vi...@rtems.org> >>> > wrote: >>> > > >>> > > On Mon, Mar 1, 2021 at 12:20 PM Joel Sherrill <j...@rtems.org> wrote: >>> > > > >>> > > > >>> > > > >>> > > > On Mon, Mar 1, 2021 at 1:05 PM Gedare Bloom <ged...@rtems.org> wrote: >>> > > >> >>> > > >> 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 >>> > > > >>> > > > >>> > > > This looks good. If it can easily be moved to the bottom of the list >>> > > > of docs, that would be great. >>> > > > >>> > > Great. I'll check it and create a patch for it (Assuming it can be >>> > > done from the docs and doesn't need anything to be done from the >>> > > website front end). >>> > > >> >>> > > >> >>> > > >> > >>> > > >> > 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. >>> > > > >>> > > > >>> > > > +1 It is what is always has been. >>> > > Great, I'll add a section in the README file. >>> > > >>> > > Regarding the README file in general: Is the current text suitable or >>> > > should we add some information like this is the separate rtems legacy >>> > > networking stack etc. ? >>> > > >>> > >>> > Add a brief note, and identify where further guidance is located >>> > (README.waf, docs.rtems.org) and keep the historical stuff I suppose, >>> > but provide a segue to it. >>> > >>> Thanks, I added it. I'll soon post an announcement to the devel (and >>> users) about the separate repo, requesting testing from concerned >>> users. >>> >>> > > >> >>> > > >> >>> > > >> Do we need to put out a call for anyone to step up to deal with >>> > > >> anything in BSPs? >>> > > > >>> > > > >>> > > > To be completely above board and proper, I think so. please post to >>> > > > both devel@ and users@ that your repo needs testing and that the >>> > > > legacy stack is soon to be removed from the main rtems.git. >>> > > > >>> > > > And make it VERY clear that anyone who plans to test, please >>> > > > speak up. We can't demand they do it immediately but it would >>> > > > be helpful to know someone is going to do it. >>> > > > >>> > > Sure, I'll post in user and devel. >>> > > >>> > > > Which NIC did you test the PC with? >>> > > > >>> > > >>> > > virtio >>> > > >>> > > >> >>> > > >> >>> > > >> > 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
