Failed to set gid privileges
peter at cadcamlab.org
Tue Sep 5 08:50:18 GMT 2000
> > The linker shouldn't need to get involved. It's not like we have
> > an unresolved symbol here: it's an unresolved *syscall*, which libc
> > should be able to handle if there's a good way to emulate it.
> Ah: I was fooled by the Slolaris (and Mutlicks) implementation, where
> the system calls are nominally part of the standard library. If the
> call doesn't exist, the linker can tell. And some calls have
> significant chunks of work which gets done in user space before
> trapping off into the kernel.
I think you are describing Linux as well -- system calls are wrapped in
libc functions. Ordinary programs never make a syscall directly. And
you are also right about syscalls that do extra work. gettimeofday()
is a great example -- the Linux kernel knows nothing[*] about
[*] Not quite true. Certain filesystems such as FAT do keep track of a
timezone offset (as a mount option, I believe), for compatibility
with legacy systems, which is the whole point of FAT support.
Point here is, unlike Solaris, the Linux kernel release is not at all
tied to the libc release. They are put out by two different groups of
people, distributed together by third parties (the distributions), and
often end up quite "mismatched", chronologically speaking, for any
given end-user. The trend in libc development is to try to incorporate
new kernel features (i.e. new syscalls) as soon as possible, but to
fail gracefully (either ENOSYS or some sort of emulation) if a
particular syscall is not available at runtime. Because you can't
assume a particular kernel at compile time.
More information about the samba-technical