tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: buffer cache & ufs changes (preliminary ffsv2 extattr support)

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 <>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index