On Tue, Mar 9, 2021 at 6:58 PM Joel Sherrill <j...@rtems.org> wrote: > > > > On Tue, Mar 9, 2021, 3:28 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote: >> >> Hello, >> >> On Fri, Mar 5, 2021 at 10:03 AM Vijay Kumar Banerjee <vi...@rtems.org> wrote: >> > >> > 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 >> > > >> >> Hi, >> >> In this proposed set of patches, I have removed telnetd from RTEMS and >> have placed it in the net-legacy repo, it seems like libbsd uses >> telnetd as well. Do we want to keep it in RTEMS and remove it from the >> legacy net repo? There are checks in for RTEMS_NETWORKING in telnetd, >> to add rtems_bsdnet.h, how do we want to deal with that? In the legacy >> repo, we can just remove these checks and let them build. > > > Move it and remove rtems networking conditional. Freezes it with legacy stack. > > Just my opinion > Is there a different telnetd in libbsd?
The longer term pseudo-goal of being able to (potentially) build multiple networking stacks and pick which one to link against may also be a consideration at this stage. > --joel > >> >> Best regards, >> Vijay >> >> > > >> > > 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
