Andi Kleen wrote:
> > So I propose: add a field to struct stat indicating the resolution of
> > the timestamps in it. It can go on the end.
> It's impossible. There is no space left in struct stat64
> And adding a new syscall just for that would be severe overkill.
There's the 4 bytes following dev_t in Glibc's definition (call __pad1
in Glibc) which isn't used by Glibc or anything else. That's still
free even when the kernel changes to 64-bit dev_t.
And if you don't like that to do that, i.e you want to guarantee that
the unused word continues to be zero for older programs (though I
can't think of any reason why it would matter), that's what the
(currently unused) flags argument to stat64() is for.
> But what you could do if you really wanted that: implement kernel
> POSIX pathconf()/fpathconf() and implement it as a parameter to
> that.
Ugh.
> I personally have no plans to implement it [pathconf], however,
> because it looks like kernel bloat to me :-)
Given the choice of using fpathconf, I'd rather accept that the
nanoseconds field is not reliable, hence I must ignore it. It does
seem a waste though - sometimes you are returning good information I
can use, other times you're not, and I can't tell the difference :-(
I'd much rather do this right. What do you think of storing the
resolution in the unused word called __pad1 in Glibc?
(Btw, it wouldn't bloat the in-core kernel inode, because only a
couple of flag bits are needed there to distinguish known resolution
values).
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:36 EST