Re: Advice on NFS support in grub

[Christoph Plattner]

This sounds good. I also prefer the second solution of the 
etherboot splitting in the two parts.

And sorry again for my missunderstandable reaction before (see other
mail !)

With friendly regards

        Christoph Plattner


Olivier Galibert wrote:
> 
> 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.
> 
> _______________________________________________
> Bug-grub mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-grub

-- 
-------------------------------------------------------------------------
private:        address@hidden
company:        address@hidden