Standalone repository for libnetworking stack

[Joel Sherrill]

Some odd questions that are mostly about making this a self-contained
entity with no loose ends.

+ Can the network demos be merged also?

+ 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.

+ 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.

This is awesome work and much appreciated.

On Fri, Feb 26, 2021 at 12:12 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Feb 25, 2021 at 6:06 PM Chris Johns <chrisj at 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.
> >
> > > 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?
> >
> https://devel.rtems.org/ticket/3850
>
> 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.
> >
> > Thanks
> > Chris
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210226/8e5e3bd1/attachment.html>