Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Dec 2000 14:54:54 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        "David E. Cross" <crossd@cs.rpi.edu>
Cc:        Axel Thimm <Axel.Thimm@physik.fu-berlin.de>, Carsten Urbach <Carsten.Urbach@physik.fu-berlin.de>, freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG
Subject:   Re: rpc.lockd and true NFS locks?
Message-ID:  <20001214145454.I4589@fw.wintelcom.net>
In-Reply-To: <200012142245.RAA69128@cs.rpi.edu>; from crossd@cs.rpi.edu on Thu, Dec 14, 2000 at 05:45:15PM -0500
References:  <Axel.Thimm@physik.fu-berlin.de> <200012142245.RAA69128@cs.rpi.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
* David E. Cross <crossd@cs.rpi.edu> [001214 14:45] wrote:
> I pruned the Cc: list a bit...
> 
> One of the email messages that you quoted has the URL for the latest
> development of the lockd code.  As far as tests go it appears to be mostly
> complete (there appears to be an issue with RPC64 on little endian machines,
> but I have not yet had a chance to crawl through the librpc code).  
> 
> As for "client" vs. "server", that is quite tricky.... since WRT NFS locking
> they are both client and server.  The "server" side is done and requires no
> modifcations to the kernel.  However a FreeBSD kernel is still unable to
> acquire an NFS lock.  This latter case is quite likely what your users are
> seeing the affects of.
> 
> In the end:  the code is there and available for those who want to test and
> play with it.  It has not been committed because it is still "broken". 
> I could do it to -current or make it a port, if someone were to tell me that
> it would be "ok" to do so.

I would like to see it in both -current and -stable.

Please take a deep breath and keep reading. :)

I think that although it's partially broken if we gave appropriate
warning to the users about the experimental nature of the code we'd
be doing them a favor by getting the code out so that _early
adopters_ so that they can give us feedback.

I do not support removing the current "fake" lockd until we've had
ironed out the issues with the experimental lockd.

I do not like _only_ having it in -current because then people will
never consider it, I have confidence that academic installations
and hobbiests would give it a shot, and who knows, maybe we'll get
a knock on the door from someone who's completed the client, after
all, what use is the client code without the server code?

As an interim solution we could put the lockd into the system as
rpc.lockd-experimental.

I think had we done this over six months ago when you made the
initial announcement we'd have enough feedback to begin ironing
out the kinks.

I want this in the user's faces, taunting and enticing them to
use it and give us feedback. :)

So can you commit this?

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001214145454.I4589>