Subject: Re: curproc removal (NFS, ...)
To: Jonathan Stone <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 05/25/2004 16:31:25
Content-Type: text/plain; charset=US-ASCII; format=flowed
On May 25, 2004, at 4:25 PM, Jonathan Stone wrote:
> Well, .. probably. Maybe. (in a fine-grained SMP kernel its less clear
> than a uP kernel, or a big-lock kernel like we have now.) It might be
> fun to do a retrospective in a year or so.
Plenty of MP-safe kernels have curproc or a curproc analogue.
> But its more than a little off-point when we're trying to pin down
> where it is (and isn't) safe to call sosend() and soreceive() from
> (say) softint context.
That is never safe anyway, for various reasons. Not the least of which:
(1) They may block.
(2) When they have fine-grained locking there, they may block
(lockmgr() locks sleep). It's not really appropriate for all locking
to be done with simplelocks; only those things that need to be locked
from an interrupt context.
I have been feeling generally uneasy with this whole notion of
"kcont-based NFS server", 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.
-- Jason R. Thorpe <firstname.lastname@example.org>
content-type: application/pgp-signature; x-mac-type=70674453;
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
-----END PGP SIGNATURE-----