Date: Mon, 11 Mar 2002 21:58:37 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Terry Lambert <tlambert2@mindspring.com>, Harti Brandt <brandt@fokus.gmd.de>, Robert Watson <rwatson@FreeBSD.ORG>, arch@FreeBSD.ORG Subject: Re: Increasing the size of dev_t and ino_t Message-ID: <p05101550b8b310e6cfae@[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 , Garance A Drosihn writes:
>
> >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.
Hmm. How did freebsd handle that transition? is that where
the ostat and nstat structs came from in stat.h?
> >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.
>
>No, we can't change the size of struct stat (binary
>compatibility!)
Now that I look at our present definition of struct-stat,
I see that we do have two spare 64-bit fields. If we were
only going to do the 64-bit ino_t, then we can do that
without breaking binary compatibility. (as long as we
fill in both a 32-bit and a 64-bit value).
The struct does not have enough spare room to also go for a
64-bit dev_t, because there are two dev_t values in the struct
and we only have one more 64-bit spare area to play with.
So, as far as userland stat() goes, a 64-bit inode is pretty
easy, but I would like to see us set the stage for the other
things we keep talking about. All of those require a bigger
struct-stat, and I can't think of any pretty way of doing
that and also maintaining binary compatibility. Let us pretend
that we "absolutely had to" increase the struct, *and* we could
not break binary compatibility, *and* we would maintain posix
compatibility for anything which was simply recompiled. If we
had to do all three of those, how could we do it?
Suggestion:
1) create a set of new routines. Call them stat64(),
lstat64(), and fstat64().
2) the new routines are exactly the same as the present
routines, except that they expect a parameter of
type 'struct stat64'.
3) (perhaps) provide duplicates of the present stat-routines,
which are called stat32(), lstat64(), and fstat64().
4) Initially create 'struct stat64' with all the same
fields at all the same sizes, but with room to expand
those fields to what we want to expand them to. Eg,
change:
__dev_t st_dev; /* inode's device */
ino_t st_ino; /* inode's number */
__dev_t st_rdev; /* device type */
time_t st_atime; /* time of last access */
long st_atimensec; /* nsec of last access */
to:
uint_32 st_dev2; /* reserved */
__dev_t st_dev; /* inode's device */
uint_32 st_ino2; /* reserved */
ino_t st_ino; /* inode's number */
uint_32 st_rdev2; /* reserved */
__dev_t st_rdev; /* device type */
uint_32 st_atime2; /* reserved */
time_t st_atime; /* time of last access */
long st_atimensec; /* nsec of last access */
5) via the magic of #define's, or maybe some loader tricks,
have it so anything which is re-compiled will call these
new routines instead of the present stat routines. They
will obtain a larger stat area, but they won't need to
make any other changes because none of the variables have
a new type. (or if they *had* to have the smaller struct,
they could call the stat32 routines)
6) over time, update the system to fill in the 64-bit
versions of all those values. "old" programs will
continue to use only the lower-order 32-bits of the
newer 64-bit versions, but that should be good enough
for most programs.
If you think about the above for awhile, and you think about the
new 64-bit architectures we are bringing up, then perhaps we
could avoid some of these steps for the new ports. Just start
out with a struct-stat which includes those extra fields for
expansion.
It is because of these new ports coming online that I want to
think about this right now, and see what we could do before
5.0-release. If we can do some of this work now, we won't have
binary-compatibility issues with FreeBSD/sparc64, FreeBSD/ppc,
or FreeBSD/ia64. If we wait until after 5.0-release, then we
do have that issue.
Is the above too ugly to consider doing? I don't think it would
be too much work to do (at least to get up to step 4).
--
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?p05101550b8b310e6cfae>