NFSv4 boot support?

[Sascha Hauer]

On Wed, Feb 28, 2024 at 10:26:15AM +0300, Antony Pavlov wrote:
> On Sat, 17 Feb 2024 09:51:02 +0100
> Ahmad Fatoum <a.fatoum at 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 at 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!

So if I understand correctly you tried passing *all* incoming packets to
picotcp and route some of them back to the barebox network stack.

Instead of passing all packets to picotcp, can't we just dispatch the
incoming packets on a per-port basis in barebox and only pass the ones
picotcp shall handle to picotcp?

So basically a struct net_connection with the handler set to the picotcp
receive function?

That way it might be possible to have the barebox network stack and
picotcp in parallel and port the handlers over to pictotcp one by one.

Sascha

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