Date: Sun, 10 Mar 2002 21:18:13 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Garance A Drosihn <drosih@rpi.edu> Cc: Terry Lambert <tlambert2@mindspring.com>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <65691.1015791493@critter.freebsd.dk> In-Reply-To: Your message of "Sun, 10 Mar 2002 15:15:27 EST." <p05101536b8b168133e4f@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <p05101536b8b168133e4f@[128.113.24.47]>, Garance A Drosihn writes: >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. There isn't much change for these actually, since they do require two new syscalls and since very few programs even think about them. This is nowhere as troublesome as off_t was. >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. No, we can't change the size of struct stat (binary compatibility!) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. 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?65691.1015791493>