Subject: Re: curproc removal (NFS, ...)
To: Jason Thorpe <email@example.com>
From: Jonathan Stone <firstname.lastname@example.org>
Date: 05/25/2004 16:49:26
In message <A3536D54-AEA3-11D8-8DE4-000A957650EC@wasabisystems.com>Jason Thorpe wri
>That is never safe anyway, for various reasons.
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?