[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Joe Hershberger <joe.hershberger@ni.com>]

On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On 22.10.2018 20:53, Joe Hershberger wrote:
> > Hi Christian,
> >
> > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
> > <christian.gmeiner@gmail.com> wrote:
> >> Hi Wolfgang
> >>
> >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> >>>>
> >>>> Prep. work to support nfs v1.
> >>> Hm... as you are putting efforts into NFS support...
> >>>
> >>> Here comes a more general question:
> >>>
> >>> I wonder if it's worth the work on NFS at all, or if we should
> >>> remove NFS support from U-Boot alltogether?
> >>>
> >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
> >>>     distros support only v4 in their default configurations.
> >>>
> >> Linux is not the only operating system used in the world. My NFSv1
> >> server runs on a vxWorks 5 device which
> >> I need to support - sadly.
> >>
> >>> 2) We support only UDP, but most standard Linux distros support only
> >>>     TCP in their default configurations (see [1])
> >>>
> >>>     [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
> >>>
> >>> Try a NFS download from any recent Linux distro (i. e. one including
> >>> nfs-utils 2.3.1 or later)...
> >>>
> >> That is true.
> >>
> >>> I feel a half-way solution is unsatisfactory, but the way for the
> >>> Real Thing (TM) is a pretty long one...
> >>>
> >>> The fact that nobody compained yet that NFS stopped working fo him
> >>> suggests that there are only very, very few users of NFS at all.
> >>> If one of these is willing to step up and fix this for real, he is
> >>> of course more than welcome.  But if not - should we not remove the
> >>> more or less obsolete code?
> >>>
> >> As u-boot is lacking TCP support this is quite a challenging task. I
> >> have seen some work in progress
> >> patches, which I have reviewed and hoped that it helps to get them
> >> further.
> > I'm trying to get those patches into a state that they are acceptable,
> > but currently they are pretty brittle. I've not actually seen them
> > work, though the contributor says they do in some case. I had to do
> > some work to have the series just not break UDP functionality, so we
> > have more work to do there.
> >
> >> I am also
> >> interested in using ftp directly in u-boot. At the moment we are using
> >> uip as tcp stack and hacked
> >> together a ftp client.
> > I was contemplating if using something like that or lwip would be
> > better than rolling our own, but my concern is both how configurable
> > those stacks are to make them lean as well as adding an external
> > dependency / forking their code into our repo. Not excited about
> > either.
>
> As the maintainer of lwIP, I already have thought about this more than
> once. My main concern however was the license (lwIP is BSD style) and

Yes, the license is a concern. I'm not a lawyer, but maybe someone can
comment on what our options are here. Wolfgang? Tom?

> the fact that it expects to always run (I don't know the U-Boot network
> stack that well, but it only runs when called, doesn't it?).

Yes, it currently works that way... it is pretty aggressive about
going away. That is something that I've wanted to rework for a while,
but haven't gotten to it. It certainly has no threads so nothing
persists. Only if you are calling into a command that uses the network
stack do you have the ability to do networking.

>
> Forking is never a good idea with open source projects. We try to
> integrate as much back into the mainline code as possible. Although we
> of course depend on the people using the stack to contribute things back.

Yes, though due to the low-level nature of U-Boot, it seems that
forking while changing as little as reasonable is the approach we've
taken in all cases I've seen in the past. Much like the bits of Linux
that are included, the forks strongly encourage changes to first be
sent to the main project, so as to support the mainline project and to
make upgrades from the mainline project much easier.

>
> Of course I don't want to push anyone (and I don't want to load myself
> with more work), but I could offer some help in getting it to run if
> anyone had a real interest. Configuration shouldn't be too much of an issue.

That's good to hear.

>
> Given the systems U-Boot runs on, lwIP would definitively be a better
> choice than uIP if you have performance improvements of tcp in mind.

That was my instinct... glad to hear from you.

>
> [BTW: a http client (a.k.a. 'wget') is already included in lwIP and with
> help of a 3rd party TLS library, it even provides HTTPS support]

Excellent.

>
>
> Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot