Re: microblaze syscall list

[Arnd Bergmann <arnd@arndb.de>]

On Sunday 27 April 2008, Michal Simek wrote:
> Arnd commented current syscall table and send me long email about(Thanks again).
> On the base on this email I did converted table for future use - for porting old
> application to new version. Below is my table with syscalls and there is a short
> description. (or http://www.monstr.eu/wiki/doku.php?id=kernel:syscall)
> 
> I counted how big impact will be syscall change to programs which are in John W
> distribution
> all programs
> mknod - 174
> rmdir - 488
> mkdir - 1128
> symlink - 404
> rename - 1536
> access - 1664
> chmod -  1122
> open - 22583 (crazy)
> ipc - 26
> 
> Only busybox
> open - 667
> chmod 44
> access 52
> rename 32
> symlink 8
> mkdir 19
> rmdir 9
> mknod 16
> 
> I thing you understand that we can't change all application per night. This is
> not possible. But we have to start with change this.

Note that the only thing you should need to change is the libc implementation
(any version of it: glibc, uclibc, klibc, ...), but not any application source
code, as the applications just call the functions that are defined in the libc.
If you have binaries that are statically linked with their libc, you'd have
to recompile or at least relink them. If you redefine data structures or
types that are used in application code, like struct stat or off_t, you
also need to recompile all user code.

Of course, as Alan and others have mentioned, even without changing any
application source code, the amount of work for that is significantly more 
than just changing the kernel.

I think you have three options here:

1. Keep the old syscall interface and just add new syscalls for the stuff
that you are currently missing. Don't change userspace at all, but live
with somewhat bloated kernels and libc forever and maintain a larger
code base in the kernel.

2. Change the syscall interface in the kernel in the way we have discussed,
and adapt the libc code along with it. Break all backwards compatibility
and start out with a new leaner ABI. Old applications can still use
your old out-of-tree kernels, or forks of that.

3. Merge only the ABI as in 2. into the mainline kernel, but use new
syscall numbers for that. Maintain an out-of-tree patch that adds the
old ABI for backwards compatibility so you can run old and new code
on one kernel if you build with that patch, but eventually phase
out the old ABI.

I won't try to force you to go either route, it's your own decision,
but you should understand the tradeoffs. I don't think there is any
value in trying to deprecate just part of the ABI and break some
binaries but not others, this will only cause hard to find bugs. Make
sure that if you decide to break backwards compatibility, you break it
in an obvious way and get the most benefit out of it.

	Arnd <><