Re: Advice on NFS support in grub

[Olivier Galibert]

On Mon, Oct 02, 2000 at 03:20:08AM +0900, OKUJI Yoshinori wrote:
>   Calm down. You should kindly accept the fact that there is at least
> one person who objects to you.

I do accept that.  I just don't like the "you should do [this
unrelated thing] instead" part.  Anyway, life goes on...


>   I'm still uncertain what you want to do. Can you elaborate on your
> motivation and your idea? Once you give us enough explanation on your
> plan, Christoph may agree with you (as well as me).

Looks like I've been unclear.  What I want is nfs support in order to
get rid of tftp which "one directory" and "no file listing"
limitations tends to get into my way.  Incidentally, I'm probably not
the only interested one, since minimal "mount this directory and get
this file from it" nfs support has been added in etherboot.

Of course, I want to do it the grub way.  That means automatic
completion where it makes sense.  With nfs, this means on the
mountpoint and on the file/directory name.  It is easy (and small
enough), the worst part is that it will require support of udp
fragmentation on receive.  Please note that this is useless for
etherboot since they have no real interactive interface.

The syntax should be around the lines of
  root (nfs,10.0.0.1,/tftpboot/jeru)
  kernel /boot/vmlinuz [...]

or
  root (tftp,10.0.0.1,/tftpboot)
  kernel /kernel-jeru [...]

We'll see what we want to do with (nd) and the tftpserver command.
The dual comma syntax can be changed to something like nfs:ip if it
fits the current parsing routines better.  Also, someday, maybe, we
may want to add dns resolution to that.


Now, the question is, how to implement that.  The current netboot code
is based on etherboot 4.6.4, with some modifications to main.c,
config.c and misc.c and a new fsys_tftp.c.  Adding a grub-level nfs
support will increase the amount of changes.  OTOH, the drivers
themselves are unchanged.

So there are two possible strategies:
- Keep it the way we are now, forward-porting the changes each time we
  resync with an etherboot version.  Looking at the current state of
  the diffs, this promises to be a pain in the future.

- Split our current netboot code between drivers (easily updated,
  because unchanged) and protocols.  Only keep the drivers part in
  sync with etherboot, and adapt the protocol part to our uses.

The second solution seems the best to me.  But if we only keep the
drivers from another project, then we can decide to get them from a
different project.  That gives oskit (aka, freebsd) and linux as
realistic options.  I personally do not think it would be wise, but it
is a possibility anyway.

Am I clearer this time ? :-)

  OG.