On Tue, 29 Jan 2002, Chris Jepeway wrote:

> > Hmmm.. That means that fixing the problems probably won't break things.
> > :-)
> Yup.  'Course, it also means that testing a fix is hard, too.

Not necessarily, just brute force. :-) If we know all of the callers, we
can see what they are doing.

> > I agree that all f/s should behave the same. The alternative to having all
> > VOPs honor SAVESTART would be to document which do and don't.
> > Just honoring it across the board would probaby be easiest.
> That was my thought, too, but I broke my head trying
> to puzzle out how ufs_rename() wants to use it.  It seems
> like ufs_rename() unconditionally steps on SAVESTART when,
> eg, calling relookup().  I guess that's to avoid VREF()ing
> the starting directory, but then there's no chance for ufs_rename()'s
> caller to use SAVESTART to hang onto cn_pnbuf.  Maybe ufs_rename()
> should turn a SAVESTART into a SAVENAME?

Some of the SAVE stuff is quite crusty. I'm not 100% how it's supposed to
work.

It used to be that ufs_rename (I think it was rename) would actually
vrele() incoming nodes, throwing away all of it's passed-in reference
counts, and then vget() them. This only worked because the caller had done
a namei() call which hung onto an extra ref, which was released after the
VOP returned.

> Then, there's the whole thing about SAVESTART vs. SAVENAME in
> VOP calls.  Those VOPs that pay attention to SAVESTART do it
> by taking it to mean "don't PNBUF_PUT() and don't let VOP_ABORTOP()
> do it, either."  Should VOPs use SAVENAME to mean "PNBUF_PUT() only
> on error?" Or should they just ignore SAVENAME?

Not 100% sure. It's been a few years. :-)

Take care,

Bill