Standalone repository for libnetworking stack

[Chris Johns]

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