Re: nfsd status.
Bill White <bill.white@griggsinst.com> writes:
> I guessed as much. For one thing, you chose to implement the portmap
> functionality inside the nfs daemon itself. Isn't this most typically
> implemented as a separate daemon?
Yes, it is. In this case, I just wanted it to work and we have not
yet made the Sun portmap run on the Hurd. (The standard code uses
lots of socket ioctls that we don't support.)
Probably the Right Thing is to make the portmap implementation in nfsd
be optional.
> 1.) Get the existing nfsd working as far as I can, in the interest of
> getting at least something working. If I see that there is too much
> missing, or if there is something which would be really hard, I
> will abandon it, but my intention is to push it through at least some
> kind of functionality. It would be very useful to be able to export
> parts of the Hurd file system.
I think there are just little bugs, and then there are parts that are
not implemented. Both should be fairly obvious to notice.
> 2.) Look into either moving the Linux portmapper daemon to the Hurd,
> along with all of SunRPC. I don't know of this is sensible or not,
> but I would like to at least cast a baleful eye upon it.
There's nothing wrong with making SunRPC work. It would be useful to
do. Automatically handling the Sun-style protocol definitions with an
interface generator is probably the Wrong Thing in general; experience
is that servers or clients which do that are much slower.
> 3.) If (2) seems to make sense, then look at porting the Linux rpc.nfsd
> daemon, along with rpc.ugidd perhaps.
The Linux demons here are grody and should not be ported. We want a
native implementation; the existing Hurd nfsd is basically the right
thing, modulo bugs.
Thomas
Reply to: