Messages in this thread | | | Date | Fri, 9 Jul 1999 16:01:44 -0400 (EDT) | From | Chris Wing <> | Subject | Re: QUESTION: 32-bit UIDs and Linux 2.3 |
| |
Jakub:
> 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/
| |