Andries Brouwer writes:
> On Sat, May 27, 2000 at 02:53:38PM +0300, Matti Aarnio wrote:
>> What is wrong with *stat64() syscalls?
>
> Not much. But perhaps they will not suffice forever.
>
> st_ino 32 bits?
> I can well imagine that we'll want more than that some time.
Yes, and I warned about this when LFS was being done.
There are several filesystems that could use a larger ino_t:
64-bit is enough for: Reiserfs, NTFS, UDF, XFS
128-bit for these: AFS, Coda
Maybe stuff half of the AFS/Coda identifier into the generation
number, which would then need to be 64-bit.
> Insane amount of padding around dev_t? It seems we are going
This is just dumb. Huge dev_t is useless because, after a certain
point, we need a dynamic /dev anyway. (with or without devfs)
Even if trillions of /dev/* files were reasonable, we still need to
deal with modern dynamic hardware -- soon it will all be like USB.
We can live with 16 bits until somebody actually has 60 thousand
active pieces of hardware on one machine.
> in the direction of describing devices by a device path instead
> of by an index number. Then 12 bytes is reasonable, but certainly
> not excessive, and some day we'll want more.
There is no need for that. Traditional backup tools can't handle
/dev in a world with dynamic hardware, so why bother? We only need
to provide random numbers to fill in struct stat. (zero works)
> I would have preferred to see stat64() as version 3 of versioned_stat.
Maybe for ports with a severely limited number of system calls... SPARC???
Otherwise, stat64v2() is better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:17 EST