Date: Sun, 10 Mar 2002 15:15:27 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101536b8b168133e4f@[128.113.24.47]> In-Reply-To: <3C8B002B.D42A8572@mindspring.com> References: <27966.1015713342@critter.freebsd.dk> <p05101533b8b0508ebb56@[128.113.24.47]> <3C8B002B.D42A8572@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 10:41 PM -0800 3/9/02, Terry Lambert wrote: >Garance A Drosihn wrote: >> >By dev_t I guess you mean the userland version of it (udev_t): the >> >combined major and minor number. >> >> Yes. The field in the 'struct stat' returned from stat(). Userland, >> posix, etc. The struct is supposed to include fields named st_dev >> and st_ino, of type dev_t and ino_t. > >Note also that POSIX requires them to be atomic types. So >"long long" need not apply, FWIW. Oh. Good point. Not that I was pushing for that, but I would have missed this point if anyone else had wanted to push for it. >If you insist on going down this path, I'd like to see a >binary compatability strategy as the first output of the >project. Well, I am not insisting on much of anything, I am just making some observations which imply to me that 32-bit fields will not always be big enough. I also think it is a major enough change that we need to spend some time to "ease into" it, which is why I'm trying to drum up some support for the idea now. As to strategy, I guess we could start by adding two new fields to 'struct stat', which would be the 64-bit ones. We could truncate the 32-bit value and put that in the current fields. Some #define would govern whether a program sees st_dev and st_ino as the 32-bit values or the 64-bit values. That's the easy solution to the struct, but of course it doesn't address all the things which work with dev_t and ino_t. That's what we would have to work on over time. Or maybe we say that we're only going to do this on new 64-bit archs, and which implies we could make a more abrupt transition, and that binary-compatability isn't (yet) a big issue. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101536b8b168133e4f>