Date: Sun, 3 Jun 2007 09:17:56 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Garance A Drosehn <gad@FreeBSD.org> Cc: Robert Watson <rwatson@FreeBSD.org>, current@FreeBSD.org Subject: Re: Pending TrustedBSD stuff, etc. Message-ID: <20070602231755.GI1010@turion.vk2pj.dyndns.org> In-Reply-To: <p0624080ac2868d814786@[128.113.24.47]> References: <20070601102516.Q77697@fledge.watson.org> <p06240806c285edb0d22f@[128.113.24.47]> <20070601211948.GB80261@turion.vk2pj.dyndns.org> <p0624080ac2868d814786@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--UoPmpPX/dBe4BELn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-Jun-01 23:12:18 -0400, Garance A Drosehn <gad@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. --=20 Peter Jeremy --UoPmpPX/dBe4BELn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGYfqj/opHv/APuIcRAlmYAJ938IW2LTHakWQYdrNWQC2rH33kjQCgmeLj uDOwlYqgAkJspEJTmuJSH3A= =n0zU -----END PGP SIGNATURE----- --UoPmpPX/dBe4BELn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070602231755.GI1010>