> I'm uneasy with your stat(2) modification.
> I think when you change the meaning of field values, you should tell the C
> library about it. glibc could do ugly tricks, like trying getuid32 syscall
> first and if it returned error, it would know the kernel does not support
> the new st_uid/st_gid fields, but that costs you a syscall for the common
> case in the future where both glibc and kernel will have large uids/LFS and
> stuff like that.
The C library will eventually need to have global variables like
'supports_32bituid' or 'supports_64bitfiles', etc., that are initialized
at program startup. I haven't done this yet, because I'm not (yet)
familiar enough with the way glibc works.
I only stuffed things into the reserved fields of xstat() so as to save on
system calls; in a previous patch I actually did add new calls for stat(),
lstat(), and fstat() (making the old calls stat16, lstat16, fstat16).
> So I'd propose creating stat64, lstat64, fstat64 system calls for all the
> platforms which need it and carefuly lay out the new structures, so that
> they will hold LFS values, large device numbers, large uids etc.
That sounds like the right approach; however, is there any reason why all
programs would not want to always use use stat64() in place of stat()?
(e.g. performance penalty on 32-bit machines?)
> Your glibc patch should care about binary compatibility and let all possible
> combinations to work (old vs. new kernel and old vs. new glibc). So, I'd
> propose not to change names of the old syscalls, it will just create severe
> confusion for glibc maintainers, rather name the new syscalls differently.
Yep, there definitely needs to be work done on glibc if the kernel changes
for 32-bit UIDs, 64-bit files, etc. It's just a pain to do, that's all :)
> > - why is the system call table for sparc populated in a 'sparse'
> > manner? is this to locate things on the same cache line, etc?
>
> Historical reasons, it was first a copy of the SunOS syscall table I think
> and then split from that, so the identical syscalls between SunOS and Linux
> have usually the same syscall number.
Okay, well then I'll stuff the appropriate system calls into my 32-bit UID
patch for Linux 2.2, and test it out on an old SparcStation 2 that I have
access to around here...
Thanks,
Chris Wing
wingc@engin.umich.edu
-
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/