On Tue, Jan 17, 2012 at 12:55:03AM +0000, David Holland wrote:
> On Mon, Jan 16, 2012 at 10:39:45PM +0100, Manuel Bouyer wrote:
> > > Indeed. But that isn't really the question. The question is really
> > > whether we're past the date for brand-new feature proposals for
> > > netbsd-6... or at least ones that involve invasive changes.
> >
> > No, the question is whenever we commit the needed bits now
> > for the feature to be pulled up without kernel API major change later,
> > or if we accept a kernel API major change in the branch after netbsd-6-0
> > is branched. "this won't ever be in netbsd-6" is not an option, I don't
> > think we can wait for netbsd-7 for this.
>
> No, that's really not the question. It's been months that we've been
> planning out what will and won't be done in time for -6. That process
> finally converged and we got a firm schedule. Now you come along with
> something major you've never mentioned during this whole time and it
> just *needs* to get in at the last minute? Really, I don't think it
> can or should.
I didn't plan to have it for netbsd-6, my plan was to pull it up later.
Then, when I started looking at it more seriously, I noticed there
would be ABI issues, which I think could be solved before the branch.
If we had a correct kernel module system (or no modules at all) the
problem woudln't exist.
>
> I mean, I could cite a dozen or two other things that "ought" to be in
> netbsd-6, for various definitions of "ought"... many of them much less
> invasive and/or dangerous. They're not going to be. It's too bad, in
> some sense, but it's already been too long since -5 was released and
> some point one needs to stop and release the system one has, not the
> system one would want if one just had another three (or six or nine or
> eighteen) months.
>
> I'm sorry if I sound testy and I'm really not trying to start a fight;
> but we really do need to get this thing branched and shipped, and what
> you're proposing could easily turn into a three-month delay (if it
> more or less works) or six or more (if it cracks wide open).
I'm proposing to add 2, unused at this time, members to 2 structures.
I doubt it will cause problems, or this would mean we have a bigger
problem with our code, and can easily be backed out if this
really is a problem.
>
> > > Changing the way the buffer cache is indexed is semantically intrusive
> > > even if it's not physically intrusive. While I think adding a type
> > > field to modify the block number is a good idea, for various reasons,
> > > it needs to be thought through, and it hasn't been yet and there isn't
> > > time to thrash it out fully before the branch deadline. Furthermore,
> > > there's the existing question of indexing by physical vs. virtual
> > > block numbers; that is not in any way a resolved issue and what you're
> > > proposing interacts directly with it, and this too needs to be thought
> > > through and there isn't time before the branch deadline.
> >
> > Yes, and I don't think we need to wait for theses questions to be
> > sorted out to have ffs2 extended attributes.
>
> Then figure out how to do ffs2 extended attributes without changing
> the buffer cache. I'm sure it can be done, and without resorting to
> gross hacks, either.
I've looked at this too. I think it can be done, but with some code
duplication and in a way we probably don't want in the long run.
This means the code to be pulled up in the branch and the code in HEAD
will be completely different.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
