libc bump subproject

Garance A Drosihn drosih at rpi.edu
Thu Apr 7 12:54:58 PDT 2005


At 12:20 PM -0700 4/7/05, Matthew Dillon wrote:
    There are some significant system types that need to be adjusted as
    well.  If we are going to make ABI changes, we're gonna want to do
    them all in one shot.
    Here are a few more:

    * 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.
    * 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.
    But even more to the point, remember way back a year or so ago
    I was talking about creating a system call compatibility layer
    in userland?  One that is mapped by the system but which runs
    in userland and replaces the current in-libc system call
    generator?
Yeah, this would be very useful.

--
Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad at xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih at xxxxxxx




More information about the Kernel mailing list