Date: Sun, 10 Mar 2002 16:52:12 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101538b8b17dc15305@[128.113.24.47]> In-Reply-To: <65691.1015791493@critter.freebsd.dk> References: <65691.1015791493@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
At 9:18 PM +0100 3/10/02, Poul-Henning Kamp wrote: >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. > >No, we can't change the size of struct stat (binary compatibility!) Arg!! I keep forgetting that the routine which *calls* stat() is the one that gets the space for 'struct stat', and it only passes a pointer to that area into stat(). Okay, well, hmm. There are solutions for that, of course, but they're all a bit uglier. Start by adding the fields to the stat structure, but don't use them for anything. This will at least get it so applications obtain more space for the structure. This change could even be MFC'ed. Then I guess add a stat64() routine, and have a #define which causes the program to see 64-bit values for st_dev and st_ino, and to also call stat64 instead of just-plain-stat. And then maybe we could have 6.0-release move to using stat64 by default, and have a stat32 for backwards compatibility. I'm being vague here because I every specific way I think of doing this has some ugly corners to it... (particularly since we can not assume that the current userland dev_t and ino_t types are necessarily big enough to hold a pointer to some other information). -- 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?p05101538b8b17dc15305>