From owner-freebsd-hackers  Tue May 13 10:08:38 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id KAA29808
          for hackers-outgoing; Tue, 13 May 1997 10:08:38 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA29788;
          Tue, 13 May 1997 10:08:29 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA10167; Tue, 13 May 1997 10:00:43 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199705131700.KAA10167@phaeton.artisoft.com>
Subject: Re: PATCHES: NFS server locking support
To: davem@caip.rutgers.edu (David S. Miller)
Date: Tue, 13 May 1997 10:00:42 -0700 (MST)
Cc: terry@lambert.org, Andrew.Gordon@net-tel.co.uk, hackers@FreeBSD.ORG,
        current@FreeBSD.ORG
In-Reply-To: <199705130106.VAA21008@darkwing.rutgers.edu> from "David S. Miller" at May 12, 97 09:06:27 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>    If you can guaranteee that you can hash the handle values in user
>    space because the handle values are not unique in the conversion
>    part between client systems, then you're all set... and it's not a
>    problem.  F_CNVT will only be called once per hash miss in that
>    case.
> 
> Why not put lockd into the kernel as a kernel thread and avoid all of
> this overhead?  That's what we do and it works extremely well...

Because FreeBSD does not have kernel threading, a FreeBSD kernel
thread is nothing more than a process that enters/starts-in kernel
space, and never leaves?

BTW: "We"?  Who has an NFS lockd?


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.