Date: Tue, 20 Jan 2009 12:52:02 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Gavin Atkinson <gavin@FreeBSD.org> 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" <imp@bsdimp.com> Subject: Re: svn commit: r187434 - stable/7/sys/amd64/conf Message-ID: <alpine.BSF.2.00.0901201248560.74507@fledge.watson.org> In-Reply-To: <1232452445.22840.21.camel@buffy.york.ac.uk> References: <200901191536.n0JFaPTN014129@svn.freebsd.org> <alpine.BSF.2.00.0901191552120.36163@fledge.watson.org> <20090119.181124.-1270972755.imp@bsdimp.com> <1232452445.22840.21.camel@buffy.york.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0901201248560.74507>