Messages in this thread | | | Date | Tue, 26 May 1998 12:39:01 +0100 | From | Jamie Lokier <> | Subject | Re: chown(2) vs lchown(2) and application breakage |
| |
Anders Hammarquist wrote: > binaries that break with unchanged syscall numbers as on the > alpha will break on i386 and m68k when libc is recompiled with the new > syscall numbers. [...] > so libc (or the > applications) need to call chown() iff lchown() fail with ENOSYS (I not > sure where would be cleanest, but I leaning towards libc). [...] > On a related note, chown() will fail with ENOSYS with a libc compiled for > > 2.1.8x on a kernel < 2.1.8x for those architectures that changed syscall > numbers unless it is handled in libc. Perhaps I should advocate that the > numbers be changed back? :-)
I think we want the following behaviour on all architectures:
1. Calling `lchown', in libc, has the appropriate effect whatever the kernel version. Newer libc should provide this function even if compiled with an older kernel; it should not have different behaviour dependent on kernel headers.
2. Calling `chown', in libc, has the effect of `chown' where possible. Again, it should not be affected by whatever kernel version is used for compiling libc.
3. libc compiled on a new kernel should not fail when run with an older kernel. This means handling the fallback, if the newer syscall returns ENOSYS.
4. Applications look for `lchown' in libc at compile time, not by checking kernel versions! If it is available, they may assume the two calls have the functionality described above.
5. Applications that depend on the difference (and use both calls) are changed to call `lchown' (in libc) when available, decided at compile time.
6. ELF symbol versioning is used so that applications compiled with an older libc and call `chown', automatically call `lchown' when using newer libc at run time. This ensures applications which depend on the difference, compiled with old libc, will work correctly with new libc. Though they may work better if recompiled.
7. More symbol versioning is used so that an application calling `lchown' in the newer libc can run with an older libc, with the behaviour specified in points 1 and 2. This is optional, it is only needed if we want to support downgrading libc version. It could make the view in the debugger confusing.
8. It is reasonable that if you use a kernel > 2.1.8x, you have to use a suitably new libc as well.
This behaviour is possible with the current Alpha syscall order. It can be done with the current i386 order, but libc has to check the kernel version at run time to get it right -- not recommended. Therefore, I advocate switching the order back on i386, soon. I would prefer to be shown that it isn't necessary though.
Then the recommended upgrade path to a > 2.1.8x kernel is:
1. Upgrade libc. 2. Upgrade affected, critical applications (dpkg, for example). 3. Upgrade to recent kernel.
Everything should still work after each step, and also work reasonably (i.e., like before) if you need to boot with an older kernel or use an older libc.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |