Re: NFSv4 boot support?

[Antony Pavlov <antonynpavlov@gmail.com>]

On Sat, 17 Feb 2024 09:51:02 +0100
Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

Hi All!

> Hello Antony,
> 
> On 05.02.24 10:59, Antony Pavlov wrote:
> > On Wed, 31 Jan 2024 22:37:50 +0100
> > Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > 
> > Hi All!
> > 
> >> Hello Dan,
> >>
> >> On 31.01.24 22:03, Dan Shelton wrote:
> >>> Hello!
> >>>
> >>> Does barebox support booting from a NFSv4 filesystem, e.g. boot from
> >>> NFSv4 filesystem into a Linux NFSv4 netroot (diskless machine)?
> >>
> >> The barebox network stack only does UDP/IP. There have been attempts to
> >> bring a TCP stack into barebox, but none have so far succeeded to
> >> make it mainline. This is a hard requirement before we can consider
> >> supporting NFSv4. I hope that lwIP could fill this gap in the future,
> >> but no one is actively continuing this work as far as I am aware[1].
> > 
> > I have started integration on picotcp into barebox in 2015, see
> >   https://lore.barebox.org/barebox/1436991230-14251-10-git-send-email-antonynpavlov@gmail.com/T/

Actually I made the first attempt to integrate picotcp into barebox in 2014,
see http://lists.infradead.org/pipermail/barebox/2014-May/019243.html

10 years is too long for this task :)

In the message http://lists.infradead.org/pipermail/barebox/2015-July/024244.html
if I understand correctly Sascha asked me to keep network stuff
users (tftp, nfs, netconsole) as intact as possible.

At the moment I understand that this task is too hard.

The problem is: the network stuff users don't rely on "a network stack"
in the true sense. E.g. tftp_handler() takes an ETHERNET PACKET on
it's input, tftp_handler() skips Ethernet and IP stuff by itself
and modifies UDP fields directly!

This week I have connected picotcp code to the existing network code
in the way that makes it possible to keep dhcp_handler() and
ftp_handler() intact. The result is ugly: barebox netdevice driver
receives frame from network, pass it to picotcp, picotcp parses
network protocol headers and extracts udp payload, next
picotcp passes udp payload back to my picotcp-to-barebox adapter,
the adapter RECONSTRUCTS ETHERNET PACKET and give it to tftp/dhcp_handler()!
This horrible approach creates more problems than it solves!

I propose another experiment: disable old network
stuff and integrate picotcp with all network applications (dhcp, tftp,
dns etc) on top of picotcp. This approach was used in the
'barebox picotcp integration (2015.06.14)' see
http://lists.infradead.org/pipermail/barebox/2015-June/023749.html
This experiment is not for use in production, probably it will break
compatibility but it will allow us to assess the benefits and drawbacks
of using a picotcp stack.

At the moment I understand that in order to achieve success in barebox
network stack upgrade I need to put more effort into ensuring the
reproducibility of the picotcp demonstration. E.g. in 2015 Sascha was unable
to get my code work, see http://lists.infradead.org/pipermail/barebox/2015-July/024304.html


> > At the moment I have WIP barebox-v2023.11 with integrated picotcp 2.1:
> > 
> >   https://github.com/frantony/barebox/tree/20231127.picotcp
> 
> Cool. Looking at Oleksij's repo, it was based on your work. How well does
> picotcp work for you? What open issues remain with the patch stack? Is the
> barebox integration actively used in projects?
> 
> Is https://github.com/tass-belgium/picotcp the official repository? This hasn't
> seen development activity in 5 years. lwIP on the other hand still sees active
> development.
> 
> Regarding the license, inclusion of BSD-licensed code is ok. You can check out
> the LICENSES/ subdirectory for the licenses covering barebox.
> 
> Cheers,
> Ahmad
> 
> 
> 
> 
> >>> We need NFSv4, because it does not need rpcbind, and combines
> >>> filesystem, lockd and other stuff all in one TCP port (2049). Site
> >>> policy also does not allow NFSv2/NFSv3, but allows NFSv4.
> >>
> >> Please note that this only concerns barebox and that kernel nfsroot is
> >> unaffected. You can load kernel and device tree over TFTP and supply a
> >> suitable command line argument to the kernel to use a NFS root.
> >>
> >> The standard net boot target does just that:
> >> https://elixir.bootlin.com/barebox/v2024.01.0/source/defaultenv/defaultenv-2-base/boot/net
> >>
> >> It specifies TCP, but hardcodes v3 currently. I guess we could drop the v3 and let
> >> the kernel decide on its own what version it will use? If that doesn't work, you can
> >> override the file locally in your environment, e.g. via CONFIG_DEFAULT_ENVIRONMENT
> >> pointing at a directory that contains a boot/net file with the appropriate
> >> changes (or just call your boot target something else like boot/nfsv4).
> >>
> >> Hope this helps.
> >>
> >> [1]: Some attempts I am aware of:
> >>      https://github.com/a3f/barebox/tree/lwip
> >>      https://github.com/olerem/barebox/tree/picotcp-2019.06.29
> >>      https://github.com/jmaselbas/barebox/commit/4a987bfdc2ad50c13126dd6290d2477c3fc0c87d
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>>
> >>> Dan
> >>
> >> -- 
> >> Pengutronix e.K.                           |                             |
> >> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> >> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> >> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> >>
> >>
> > 
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 


-- 
Best regards,
  Antony Pavlov