lkml.org 
[lkml]   [2008]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: microblaze syscall list
    Date
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2008-04-27 22:19    [W:2.723 / U:0.876 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site