Date: Fri, 26 Aug 2011 10:11:36 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: perryh@pluto.rain.com Cc: avg@freebsd.org, freebsd-arch@freebsd.org Subject: Removing Giant from VFS in 10.0 (was: Re: skipping locks, mutex_owned, usb) Message-ID: <alpine.BSF.2.00.1108261007110.48200@fledge.watson.org> In-Reply-To: <4e576127.Suqlhieb0FMDx8cB%perryh@pluto.rain.com> References: <4E53986B.5000804@FreeBSD.org> <201108230911.09021.jhb@freebsd.org> <4E564F15.3010809@FreeBSD.org> <201108250945.24606.jhb@freebsd.org> <4e576127.Suqlhieb0FMDx8cB%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Aug 2011, perryh@pluto.rain.com wrote:
> John Baldwin <jhb@freebsd.org> wrote:
>
>> ... acquire Giant.
>
> Last I heard, Giant was dropped in 8.0 (and that was the reason for isdn and
> sio being dropped). Has it been reinstated? If so, should isdn and sio
> also be reinstated?
Giant persists in a number of places in the kernel, although most mainstream
subsystems have been Giant-free for several years. Giant compatibility was
removed from the network stack for 8, and I had hoped Giant compatibility
would be removed from VFS for 9. That hasn't happened, but there are signs it
may happen for 10. The main constraints there are that a pool of useful file
systems remains unconverted to the new locking world order -- particularly,
smbfs.
I'd love to see someone take the bull by the horns on this one (Attilio?) --
the process we used for the network stack can probably be replicated there
without too much difficulty:
(1) Enumerate all remaining file systems dependent on Giant (probably already
in the wiki, but review and update).
(2) Post a Giant deprecation plan for VFS to arch@, current@, and fs@,
allowing for substantial windows of time between "Announce removal plans",
"Disable build of non-conforming parts", "Remove non-conforming parts",
and with plenty of solicitations for help in fixing non-conforming parts.
(3) Put in some of the legwork to help fix critical things -- mostly
netsmb/smbfs.
I will commit to either (a) making Coda MPSAFE for 10.0 or (b) removing it
from the tree myself if I or someone else doesn't do it in time. But we do
need more hands if we want to bring some of the legacy file systems forward --
especially things like nwfs/netncp, smbfs/netsmb, hpfs, etc.
We also need to start announcing this early in the 10.0 cycle so that
third-party file system developers for FreeBSD -- especially anyone interested
in things like OpenAFS and Fuse, can do appropriate updates there as well.
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1108261007110.48200>