On Wed, Jan 18, 2012 at 02:27:30PM -0500, Thor Lancelot Simon wrote: > On Wed, Jan 18, 2012 at 04:24:27PM +0100, Manuel Bouyer wrote: > > On Wed, Jan 18, 2012 at 10:03:02AM +0100, Manuel Bouyer wrote: > > > It's not "breaking it on the branch", it introducing a backward compat > > > problem with the lfs modules, for those who are using the lfs > > > module (it's statically built into the kernel by default). > > > > > > I didn't feel it's a problem, but if it is it can fixed in a simple way: > > > I could add the extra parameter to UFS_BALLOC() now, but not use it. > > > > I'd add that the compat problem is what you run a new ffs module with > > an older lfs one. That would mean one has to update only some modules to > > run into it. > > So, leaving aside the question of whether this kind of code to support > a new feature should go in so soon before a release -- it seems to me > that the "compatibility problem" here is basically illusory. To see > it, you'd have to be running the branch, using LFS as a module (which > is not the default configuration), then update to a newer snapshot of > the branch, then update only some of your modules, right?
that's it for the changes in sys/ufs/ufs; the changes to struct buf affects much more modules. > > So, who cares? I don't, but others may have a different view. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --