On Mon, 4 Aug 2003, YAMAMOTO Takashi wrote:

> hi,
>
> > Hmm, I somehow thought that the discussion about this was closed
> > with conclusion that the added memory requirements for every vnode
> > are not really worth the added functionality.
> >
> > Or do I recall incorrectly?
>
> i didn't see such conclusion.
>
> Simon Burge suggested to make it optional.  and i answered that
> i don't think it's worth to be optional and it's a first step to
> make vnode allocation more dynamically.  then the discussion came to an end.
> so i thought that he had been convinced.

I agree that we should either do this or not do this; making fields in
struct vnode come & go with kernel options will be a mess for LKMs.

> matthew green once expressed a doubt about its worth.
> but he said a positive comment (privately) after that.  then i thought that
> he had changed his mind.
>
> Bill Studenmund suggested "heavyly-poolify" approach.
> afaik, what i committed isn't conflict with his idea.

Correct. My understanding of your changes is that they will be needed both
for what you propose and for what I had in mind. Also, they look like
something we need anyway; we really should be killing name cache entries,
not waiting to notice a changed ID. Also, as I understand it, there is a
slim chance that we will re-use a vnode and the name cache won't notice
(one in 2^32, so small, but not non-zero).

> i can't recall any other objections.

I think that change is fine.

Take care,

Bil