[PATCH v2 0/4] NFSv1 support

Peter Robinson pbrobinson at gmail.com
Fri Mar 24 14:13:42 CET 2023


On Fri, Mar 24, 2023 at 1:05 PM Christian Gmeiner
<christian.gmeiner at gmail.com> wrote:
>
> Hi Peter
>
> > >
> > > Hi Peter,
> > >
> > > Am Fr., 24. März 2023 um 11:10 Uhr schrieb Peter Robinson
> > > <pbrobinson at gmail.com>:
> > > >
> > > > On Fri, Mar 24, 2023 at 9:35 AM Christian Gmeiner
> > > > <christian.gmeiner at gmail.com> wrote:
> > > > >
> > > > > Hi Peter,
> > > > >
> > > > > > >
> > > > > > > This patch series adds support for NFSv1 and is more
> > > > > > > or less a rebased version of an older series.
> > > > > > >
> > > > > > > During V1 there was a discussion if it really makes sense
> > > > > > > to bring more features into the network stack of U-Boot as it
> > > > > > > is just a bootloader. As TCP support landed I thought I might
> > > > > > > give this patch series another try.
> > > > > >
> > > > > > So the real question is what use does this bring? TCP is useful
> > > > > > because it can enable support for modern features like UEFI HTTP boot.
> > > > > > What is the use of NFSc1? The Linux kernel is removing support for
> > > > > > NFSv2 and according to wikipedia v1 was only ever used internally to
> > > > > > Sun so I'm not sure what the wider use of this functionality would be?
> > > > > >
> > > > >
> > > > > You know there are other operating systems used in the wild. One of them is
> > > > > vxworks. The company I work for supports software versions for more than 10
> > > > > years and customers do not want to update to newer software versions
> > > > > as the process
> > > > > of approval for wind turbines/parks is very costly and time intensive.
> > > > > For security
> > > > > issues we provide patches for older versions that the customers are
> > > > > switching to.
> > > >
> > > > Are there deployments that are updating to new versions of U-Boot that
> > > > require NFSv1 though?
> > > >
> > >
> > > Sadly, yes .. There are so called drop-in replacements for "processor
> > > modules" where
> > > we update the old design (e.g. AMD LX800 based 26G MHz one) to a new
> > > recent Intel SoC.
> > > Our customer can order a replacement HW for the old LX800 based design
> > > and they get
> > > the new one with fully compatible software.
> > >
> > > > > We are shipping devices right now which are based on vxworks 5. Some
> > > > > customers are using our "processor modules" as NFS server for e.g. other
> > > > > "processor modules" to boot from. If you want/need I can go into further details
> > > > > about our use case.
> > > >
> > > > So they're using a 25 year old version of vxworks with the latest
> > > > version of U-Boot? And vxworks supports only NFSv1, and not NFSv2,
> > > > which has been out since 1989 and was the first version that even Sun
> > > > supported publicly?
> > > >
> > >
> > > There are newer versions of NFS supported on more recent vxworks
> > > versions but as our
> > > customers do not want to change software of an approved wind turbine we need to
> > > support the old feature.
> > >
> > > Also we are allowed to include only critical fixes in patch version,
> > > which can be used
> > > without the whole approval process. For any new feature our customer would
> > > need to redo the whole approval process.
> >
> > Yet they allow you to update the entire version of U-Boot to the latest one?
>
> U-Boot is used as coreboot payload and both together are the bios. None of our
> customers do bios updates in the field as the risk of bricking the
> device is too high.
>
> >
> > I understand how the process works when they don't want to change
> > things, but it doesn't make sense to update U-Boot to the latest
> > version yet not other pieces of the infrastructure. NFSv1 was
> > basically obsolete from the outset because Sun's first public release
> > was v2.
> >
> > It doesn't make sense to me to upstream a long obsolete version, and
> > no doubt insecure, version of a protocol which is seemingly used by a
> > single customer of yours.
>
> I am fine with that decision .. but I hope you know that NFSv2 is an
> insecure version too!

Oh I'm well aware of that, it's at least been more widely reviewed and
the issues are better known. Personally I've never particularly seen
the point of NFS in a firmware at all. These days I think HTTP would
provide equivalence of functionality with the better support for
things like proxy/caching/CDN and other such functionality.

> >
> > > >
> > > > > So I know It is a quite specific use case but we want to upstream most
> > > > > of our downstream
> > > > > patches.
> > > > >
> > > > > Btw. if this patch series will not land does this mean NFSv2 will die too soon?
> > > >
> > > > At least NFSv2 is supported to some degree whereas it seems NFSv1 is
> > > > something that's special to vxworks, how are people supposed to test
> > > > it? I don't see any tests in your patchset and I'm not sure how it's
> > > > useful outside of the legacy vxmworks use case.
> > > >
> > >
> > > I thought that this unit test topic will pop up and we have written
> > > some last week. I will
> > > include them in the next version of this patchset.
> > >
> > > Btw why are there no NFSv2, NFSv3 unit tests in U-Boot? How are people
> > > supposed to
> > > test it?
> >
> > The NFSv2 code was contributed before it was decided that new
> > functionality should come with tests that can run in CI.
> >
> > Where would the NFSv1 server come from for this for testing in CI?
>
> You convinced me to stop thinking about upstreaming NFSv1 support.
>
> --
> thanks
> --
> Christian Gmeiner, MSc
>
> https://christian-gmeiner.info/privacypolicy


More information about the U-Boot mailing list