Re: microblaze syscall list

[Arnd Bergmann]

On Monday 28 April 2008, John Williams wrote:
> 
> Until very recently with the MMU support added to the CPU (and upcoming 
> MMU support patches for MicroBlaze), all apps were statically linked 
> anyway. So, this is not too much of an issue I don't think.
> 
> Because the CPU is so configurable re: instruction set and features, it 
> is common to rebuild your entire userland and libs + kernel in one go. 
> If you add support for HW integer mul or div, barrel shift etc, you need 
> to rebuild not just the kernel but apps and libs as well.  Or rather, 
> rebuild apps, and relink against a different multilib'd libc.

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.

> So, the issue seems not so much that there's a bunch of legacy binaries 
> out there that will break, but rather that there will be a dead-zone 
> period in which the kernel is exporting an ABI that is simply not 
> available in the C libs and existing toolchains.  We should be doing all 
> we can to encourage individual developers and distro maintainers (like 
> PetaLogix) to base from the kernel.org tree.

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.

> Maybe I misunderstand, but is there an option 1(a) where we keep the 
> old, add the new, and suffer the bloat for a short period until the 
> toolchains and C libs catch up and we remove out the old interfaces?
>
> Are the old and new syscalls necessarily overloaded onto the same 
> numbers?  We'd obviously like to be as "standard" as reasonably possible 
> regarding syscall numbers

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 <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/