From owner-svn-src-all@FreeBSD.ORG Tue Jan 20 12:52:03 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 360D81065673; Tue, 20 Jan 2009 12:52:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0DB568FC13; Tue, 20 Jan 2009 12:52:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 941B746B06; Tue, 20 Jan 2009 07:52:02 -0500 (EST) Date: Tue, 20 Jan 2009 12:52:02 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gavin Atkinson In-Reply-To: <1232452445.22840.21.camel@buffy.york.ac.uk> Message-ID: References: <200901191536.n0JFaPTN014129@svn.freebsd.org> <20090119.181124.-1270972755.imp@bsdimp.com> <1232452445.22840.21.camel@buffy.york.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: sobomax@FreeBSD.org, svn-src-stable-7@FreeBSD.org, svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, "M. Warner Losh" Subject: Re: svn commit: r187434 - stable/7/sys/amd64/conf X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 12:52:04 -0000 On Tue, 20 Jan 2009, Gavin Atkinson wrote: >> : Are you going to modify UPDATING to say that "options NTFS" will now be >> : required where it wasn't previously on amd64? Also, insta-MFC's are generally >> : a bad idea, even for changes believed harmless, as they often have unexpected >> : side effects. >> >> Especially since NTFS works very well in 6.x and I think in 7.x. It is >> only in -current that there are issues exposed by other work... > > Do you know which other work exposed these issues? Or is it broken but > nobody knows why? > > If the cause is known, this might make a good "junior kernel hacker" task, > or whatever that page is called now, especially given other file systems > have been changed and may serve as example code. I'm not sure if it's a stability issue per se, rather that as kernel interfaces for VFS are evolved to support more parallelism, etc, file systems without active maintenance are at risk of becoming less functional and eventually being dropped. I think the context of the previous thread was Attilio inquiring about expelling some of the less-recently maintained file systems from the kernel so as to make redoing VFS interfaces easier (since he'd have to touch fewer file systems). There may be other stability issues as well, needless to say. One of the biggest issues will be if we want to, at some point, remove all the scaffolding used to support non-MPSAFE file systems, as locking down file systems requires both quite a bit of expertise and quite a bit of time. On a similar note, in the network stack, we jettisoned netatm and neti4b support as they didn't have maintainers and there was no one to make them MPSAFE. We're going to do the same for network device drivers that aren't MPSAFE in the near future in order to remove the last bit of scaffolding there -- I originally planned to remove IFF_NEEDSGIANT last year, but deferred it since it seemd the usb2 project was working towards providing MPSAFE USB network device drivers, which is seems (on the whole) to have now done, so I should restart the removal of IFF_NEEDSGIANT for 8.0. Robert