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. > 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. Do the new python files need to pep8 formatted? :) [ https://gitlab.com/ita1024/waf/-/tree/master/playground/pep8 ] In bsp_drivers.py is there a waf node way to find the sources rather than a python os walk? [ https://waf.io/apidocs/Node.html#waflib.Node.Node.ant_glob ] Should the README reference rtems_waf and all the configure options it supports? Do we need a LICENSE file? > > 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 > 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. Do we have a ticket for this task? > 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. Thanks Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel