If this is the common case, that is a good argument for breaking the ABI
completely now. You will just require a new libc build with a new kernel.
As far as I can tell, these distrbutions typically come with both
kernel and libc source code together. It would be logical to just
require updating both here as well.
It's more than just the syscall numbers that should ideally change.
The other changes I would recommend include moving to large file
types (64 bit off_t), 32 bit UIDs, cleaned up sysV-IPC types, and a
few others. All these break the user code in the same way that changing
the instruction set does, which is the reason that we can't change
any of the existing architectures that started out in the old days.
The syscall numbers are entirely arbitrary, that's why I suggested
in my approach 3. that you introduce a new set of syscall numbers for
the new ABI, and keep compatibility with the old calls in their existing
numbers as an out-of-tree patch.
If you assume that the user recompiles the libc and the kernel together,
you can obviously change syscall numbers and data types in any way you
please, but still I'd suggest you don't change them after the kernel
gets merged upstream.
How about this strategy then:
* Change all the data types and syscall numbers in the -for-2.6.27
branch to only include the minimal set, and a modern ABI
* Add the old interfaces as an out-of-tree patch that adds source
level compatibility with the old libc, but does not modify any
of the new interfaces, so that a patched kernel can run all binaries
built for the upstream version.
* phase out the old source interface gradually, as all users update
their libc source code.
This way, early adopters suffer the pain of incompatibility twice, but
get the clean kernel port quickly.
Arnd <><
--
