Re: microblaze syscall list

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 <><
--
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/

Relevant Pages

  • Re: microblaze syscall list
    ... Until very recently with the MMU support added to the CPU (and upcoming ... is common to rebuild your entire userland and libs + kernel in one go. ... You will just require a new libc build with a new kernel. ... It's more than just the syscall numbers that should ideally change. ...
    (Linux-Kernel)
  • Re: microblaze syscall list
    ... as the applications just call the functions that are defined in the libc. ... 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. ... 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. ... Change the syscall interface in the kernel in the way we have discussed, ...
    (Linux-Kernel)
  • Re: [PATCH 6/7] remove all remaining _syscallX macros
    ... kernel is the one who ends up writing the libc syscall ... documentation on using kernel interfaces. ... I assume these were very _early_ glibc in when the port was new? ... instead of libc's syscall(), and which can be fixed fairly easily. ...
    (Linux-Kernel)
  • Calling syscalls from x86-64 kernel results in a crash on Opteron machines
    ... We have a piece of kernel code that calls some system calls in kernel ... I have tried standard _syscall() macros from ... The assembly dump of the umaskcalled via _syscalland via ... 0x0000000000000055: nop ...
    (Linux-Kernel)
  • Re: [take24 0/6] kevent: Generic event handling mechanism.
    ... for the latest stable lighttpd version and test it with kevent. ... This is as far as the kernel is concerned. ... How should it know which syscall should be interrupted when special syscall ... keep the interface as small as possible. ...
    (Linux-Kernel)