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

[Tom Rini <trini@konsulko.com>]

On Mon, Oct 29, 2018 at 08:13:37PM +0000, Joe Hershberger wrote:
> 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?

We have BSD-2 and BSD-3 clause code today in the tree, usually because
we've had need to bring in existing code under such license.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181029/084e2b03/attachment.sig>