Re: Pending TrustedBSD stuff, etc.

On 2007-Jun-01 23:12:18 -0400, Garance A Drosehn <gad_at_FreeBSD.org> wrote:
> With distributed filesystems such as OpenAFS, a 64-bit dev_t would
> be very useful.  With OpenAFS, a single system can reference AFS
> volumes from hundreds of sites, and each site can have tens of
> thousands of separate AFS volumes.  Given the way AFS works, each
> AFS volume would pretty much have to be a separate st_dev device.
> (this has been gone over in previous discussions of stat changes...)

That makes sense.  dev_t is supposed to be fairly opaque and
userland programs don't have much need to either manipulate it
and are unlikely to have referred to it by some native type
(eg int or long).  It has already grown from 16 bits to 32 bits
so any code that used to incorrectly treat it as a short is
either already broken or has already been fixed.

>> What other struct stat changes are up for discussion?
>
> I assume the timestamp-related ones.  Either for going to a 64-bit
> time_t on the platforms we don't already have it (or at least
> reserving the room for 64-bit time_t's), or maybe increasing the
> resolution to sub-second.

struct stat already includes 'struct timeval' so it has nanosecond
resolution.  time_t is 64 bits on everything except powerpc and i386.

Changing the size of time_t is likely to have fairly far-reaching
consequences and I suspect that a couple of weeks before branching 7.0
is not the right time to do it.  Unlike dev_t, time_t is commonly
manipulated within userland code and old code is quite likely to
assume it is a long.

-- 
Peter Jeremy