Re: libc bump subproject

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>
:>     * Bump ino_t (and thus stat.st_ino and dirent.d_fileno and
:>       others) to 64 bits.  This has been needed for a very long
:>       time.  (If I thought I could get away with making it 128
:>       bits I would).
:
:Please bump dev_t to 64 bits while you are at it.  This may seem
:excessive for most situations, but it makes sense for some kinds
:of distributed filesystems, such as OpenAFS.  I'm still hoping to
:do that for FreeBSD (for 6.0-release?), although I haven't made
:any noises about it recently.

    dev_t (well, __dev_t and udev_t from the kernel's point of view)
    is a bit harder to handle, we might actually have to rename a few
    system calls to do that safely (e.g. mknod() -> mknod64()).  It has
    the same problem that off_t had when it went from 32 to 64 bits
    (many years ago).

:>     * Bump nlink_t (and thus stat.st_nlink) to 32 bits.
:>
:>     * Bump stat.st_gen to 64 bits.  This has also been needed for
:>       a very long time.
:
:Hmm.  What does this field keep track of?  (I see that the include
:file says "file generation number", but what does that mean in a
:practical sense?)  I don't think I have ever seen it used.
    
    Its the generation number for the inode... it allows you to tell
    if the inode has been reused for another purpose (e.g. you remove
    a file and sometime later create a new file that reuses that inode).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>