Re: Advice on NFS support in grub

[Olivier Galibert]

On Tue, Oct 03, 2000 at 09:31:52AM +0900, OKUJI Yoshinori wrote:
> From: Olivier Galibert <address@hidden>
> Subject: Re: Advice on NFS support in grub
> Date: Sun, 1 Oct 2000 19:36:19 -0400
> 
> > 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.
> 
>   Hmm, I think the completion of file names would be easy, but how do
> you support completion of mountpoints?

mountd (which you have to contact to get the file handle for the mount
point no matter what) gives you a list of the exports for a particular
host when queried.  You can test it with showmount -e <host>.  So
while you can't complete on the host name/ip, once you have it you can
complete on the mountpoints for this particular host.


> > 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.
> 
>   I can't understand this reason. If my understanding is correct,
> fragmentation is required, because NFS usually uses 8192 bytes-length
> packets and some network interfaces don't support so large packets
> physically. Why is it concerned if the interface is interactive or
> not?

Your understanding is incorrect.  You can set a buffer size for nfs
data communications, this is what etherboot does.  Putting 1024 there
avoids fragmentation.  You can't set a buffer size for directory
listing (well, you can, but linux ignored it until very recently, and
I don't know what the situation is with other oses), and you can't set
one for mountd export list reporting.


>   Personally, I don't want to change the device syntax itself. So I
> suggest this instead:
> 
> netdevice nfs 10.0.0.1 /tftpboot/jeru
> root (nd)
> kernel /boot/vmlinuz

Ok. Otoh, I liked the symmetry with local filesystem operations.  Oh well.


>   This sounds good. We have already modified the protocol code,
> anyway. As long as we can use the original drivers with no or few
> modifications and your code is compact enough, you may do whatever you
> like.

Good.  I'll try to make nice enough code.

  OG.