According to Bill Studenmund:
>
>You're correct about when generation #'s get changed. But they do also get
>changed on inode allocation. Check out ffs_valloc() under the "Set up a
>new generation number for this inode." comment. :-)
>

I have not looked at this yet but Bill is making sense to me.

>> I would think you'd use dev/ino/generation triplets, actually -- the
>> generation number is there to make sure someone hasn't supplanted the binary.
>
>Right! That's exactly why its changed in ffs_valloc, and why it's needed.
>

Well, you really only need to uniquely identify the file on the file
system.  If the file has been modified then either the unique
identifier will not match the known good files or the signature will
be different.  Either way the file would not be executed.

>Since all the info in a filehandle is needed, I think it'd be much better
>if they were used instead of dev/ino/gen# tuples. I think using explicit
>dev/ino values in the interface is wrong, and will generate a lot of
>resistance (from me :-) over something which really isn't an essential
>point of the design. :-)
>

I accept what you are saying and will fix it :-)

I have also had a bit of a rethink on the issue of overwriting running
binaries.  I should be able to stop the overwriting of just currently
running binaries and actually making ETXTBSY work - I think I can see
a way of doing this.  Is this a desirable thing for a standard kernel?

>
>I think the thought was that if the generation #'s were tied to the
>in-memory inode, that eventually that number would come back, and the
>wrong file would be validated.
>

Exactly what I meant.

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================