Microblaze toolchain - libc - Kernel

This is a discussion on Microblaze toolchain - libc - Kernel ; Hi John W, is it any movement in libc? I would like clear code around syscalls. Thanks for info, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Microblaze toolchain - libc

  1. Microblaze toolchain - libc

    Hi John W,

    is it any movement in libc?
    I would like clear code around syscalls.

    Thanks for info,
    Michal
    --
    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/

  2. Re: Microblaze toolchain - libc

    Hi Michal,

    On Sun, 2008-05-11 at 16:05 +0200, Michal Simek wrote:


    > is it any movement in libc?
    > I would like clear code around syscalls.


    I can't see anything radical happening with glibc / uClibc in the short
    term. My suggestion is you make sure the kernel builds with current
    toolchain.

    I'm not personally concerned about minor bloat of adding syscalls like
    openat() that are not currently used - 1 or 2 K for extra entries in
    syscall table, and a few hundred bytes per sys_wrapper really is not on
    the radar if glibc is considered a sensible library for Microblaze +
    MMU!

    Regards,

    John


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

  3. Re: Microblaze toolchain - libc

    On Monday 12 May 2008, John Williams wrote:
    > > is it any movement in libc?
    > > I would like clear code around syscalls.

    >
    > I can't see anything radical happening with glibc / uClibc in the short
    > term. *My suggestion is you make sure the kernel builds with current
    > toolchain. *


    What happened to the idea of making it an add-on patch for the short
    term then?

    I think you should use the short generic syscall list in the mainline
    series, and add source level support for uClibc back in as an out-of-tree
    patch, under an #ifdef.

    I guess that you can mostly do this by adding back the currently
    required syscalls for uClibc at the end of sys_call_table, and
    introducing a new file with the old implementation of the removed
    arch specific calls (ipc, vfork, mmap, ...).

    BTW: after a private discussion I had with some other kernel hackers,
    I believe now that it will be easier for you to leave off_t as
    32 bit but instead make sure that you only list the syscalls using
    loff_t, e.g. stat64 instead of new_stat, contrary to what I claimed
    earlier. You should probably try that yourself and do whatever
    is easier to implement in uClibc.

    > I'm not personally concerned about minor bloat of adding syscalls like
    > openat() that are not currently used - 1 or 2 K for extra entries in
    > syscall table, and a few hundred bytes per sys_wrapper really is not on
    > the radar if glibc is considered a sensible library for Microblaze +
    > MMU!


    You still have it backwards -- you need to have openat() anyway because
    applications can legally call that function, and if uClibc doesn't have
    it, that's just a bug. The discussion was about leaving out the open()
    syscall in favour of a libc based implementation based on openat().
    Besides, these syscalls don't matter much, as you said those only save
    a few bytes.
    The real killers are uid16, 32 bit off_t, old style signals and some
    minor annoyances things like sys_ipc(). If you change those, you might
    just as well get it right because you're breaking compatibility already.

    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/

+ Reply to Thread