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

[Simon Goldschmidt]

On 22.10.2018 20:53, Joe Hershberger wrote:
> Hi Christian,
>
> On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
> <christian.gmeiner at gmail.com> wrote:
>> Hi Wolfgang
>>
>>> In message <20181001094646.11539-1-christian.gmeiner at gmail.com> you wrote:
>>>> From: Thomas RIENOESSL <thomas.rienoessl at 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 
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?).

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.

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.

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.

[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]


Simon