On Wed, Jan 18, 2012 at 10:21:13AM +1100, matthew green wrote:
> > I am in agreement with Manuel. Without going into argument on BSD LFS
> > design issues, current code is way too far from being anywhere stable
> > and reliable. It should not block any progress in other subsystems.
>
> irregardless of what LFS is or isn't, breaking it on the branch is
> not acceptable. you might not use it or trust it, but there are
> people who do -- the people who maintain it -- and the same argument
> applies equally to their work as to any other work.
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.
>
> this is for a change that i'm not even convinced is a good thing,
Because you don't need extended attributes ?
> let alone deserves to invade changing the buffer cache so close to
> a release.
>
>
> more generally on this issue:
>
> i don't think it matters if netbsd-6 and -current end up having
> non-trivially different implementations of this code. what matters
> most is that we (a) release netbsd-6 soon and (b) keep it stable.
>
> if non-trivial changes are necessary for ffsv2 extattr support to
> be part of netbsd-6 then i think that those changes have missed the
> boat. if those changes can be kept localised, but not entirely
> clean, then netbsd-6 can still have the feature without the
> potential for disrupting the release.
OK, so I guess we're back to using a B_ALTDATA in b_flags for netbsd-6.
It has more potential to break things, but doesn't break backward
compatibility for modules and so doesn't need changes to the buffer
cache now.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
