In message <A3536D54-AEA3-11D8-8DE4-000A957650EC@wasabisystems.com>Jason Thorpe wri
tes
>That is never safe anyway, for various reasons.  

Jason,

As you used to be so fond of saying: ``BZZT''.  There are non-empty
envelopes where its's safe to do this in most CSRG-derived networking
tacks. There are other very fine-grained-SMP kernels, using BSD
networking code.where its safe to do the equivalent.

Sure, it may not be safe _in general_: the point is to find where it
is safe, (and document it so it stays that way).


>(2) When they have fine-grained locking there, they may block 
>(lockmgr() locks sleep).

(Deep breath) Then maybe that's a design flaw in the lockmanager which
should bloody well be fixed.? this has peeved me for... years, now.

I see no a-priori reason to expect that a lockmanager -- which IIRC,
was originally designed for relatively heavyweight locks, for
filesystem-internal locking --- is going to give the right APIs for
the much lighter-weight locks needed for true fine-grained locking.

But, okay, maybe we stick with the current locks, and we currently
have as softint context becomes a separate kthread. (I hear that's
more or less what FreeBSD 5.x does.) Or some two-level scheduler
cruft, which is what DU/Tru64 did.

>I have been feeling generally uneasy with this whole notion of 
>"kcont-based NFS server",

Its not just for NFS, but  let that ride.

> precisely because I don't think many people 
>have their head wrapped around what can and can't be done in interrupt 
>context, nor do they necessarily understand the broader consequences of 
>changing code TO work in an interrupt context.

... then they're very unlikely to be able to get their heads wrapped
around getting code to work well with true fine-grained locking, either?