Re: libc bump subproject

[Garance A Drosihn <drosih@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx