[PATCHES] glibc 2.1, Linux, and chown
Jim Pick
jim@jimpick.com
Sat Dec 12 17:47:00 GMT 1998
Richard Henderson <rth@cygnus.com> writes:
> On Sat, Dec 12, 1998 at 10:17:18AM -0800, Jim Pick wrote:
> > Alpha is different.
>
> At issue is that Alpha didn't go through the same syscall number
> changes as everyone else. We'd been following DU, which already
> defined both chown and lchown.
Fair enough. It's obvious I didn't get the issues right the first
time around.
Let me see if I understand this:
Note: 2.1 = 2.1.124 and 2.0 = 2.0.36
Arch KVer Syscall Behaviour
====== ==== ======= =========
i386/ 2.0 16 = __NR_chown Does not follow symlinks
m68k/
ppc
i386/ 2.1 16 = __NR_lchown Does not follow symlinks
m68k 182 = __NR_chown Follows symlinks
ppc 2.1 16 = __NR_lchown Does not symlinks
181 = __NR_chown Follows symlinks
alpha 2.0 16 = __NR_chown Does not follow symlinks (?)
alpha 2.1 16 = __NR_chown Follows symlinks
208 = __NR_lchown Does not follow symlinks
sparc 2.0 16 = __NR_chown Does not follow symlinks
sparc 2.1 13 = __NR_chown Follows symlinks
16 = __NR_lchown Does not follow symlinks
mips 2.0 __NR_Linux+16 = __NR_chown Does not follow symlinks
mips 2.1 __NR_Linux+16 = __NR_lchown Does not follow symlinks
__NR_Linux+202 = __NR_chown Follows symlinks
I read some of the original discussions:
http://www.linuxhq.com/lnxlists/linux-kernel/lk_9801_03/
http://www.linuxhq.com/lnxlists/linux-kernel/lk_9801_04/
http://www.linuxhq.com/lnxlists/linux-kernel/lk_9802_01/
>From http://www.linuxhq.com/lnxlists/linux-kernel/lk_9801_04/0164.html ,
Richard Gooch <rgooch@atnf.csiro.au> wrote:
Solaris: chown() traverses the link
SunOS: chown() hits the link
IRIX 6: chown() traverses the link
DEC Unix V3.2: chown() traverses the link
It looks like the Alpha 2.1.x kernels do have changed behaviour on
syscall 16 (chown), breaking compatibility with Linux 2.0, because of
the desire to be syscall compatible with Digital Unix.
The other ports did not break compatibility, because they were able to
renumber the syscalls - so the old chown call became lchown (which
better describes what it did).
That's consistent with the behaviour of Debian's dpkg binary from the
stable distribution breaking when used with the 2.1.x kernel, which I
experienced (about 6 months ago, on a client's machine).
Here's a reference to the problems with dpkg:
http://www.linuxhq.com/lnxlists/linux-kernel/lk_9805_04/msg00492.html
Basically, the solution is to tell dpkg to use lchown() - but glibc
first needs to be patched to handle chown/lchown for the 2.0.x kernels
that only have chown (which is really lchown).
Joel's proposed patches are for emulating the new chown behaviour on
the old kernels (which really only had lchown behaviour built in). I
don't really understand exactly how it works (with symbol versioning
and all that), but it does seems like the right thing to do.
I'm not really clear on why you felt that the alpha glibc doesn't need
Joel's patches. Wouldn't it be a good thing if glibc 2.1 provided a
chown() implementation on 2.0.x kernels that was compatible with the
2.1.x kernels?
Cheers,
- Jim
More information about the Libc-alpha
mailing list