Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)

From: Adrian Bunk (bunk_at_stusta.de)
Date: 01/12/05

  • Next message: Christoph Hellwig: "Re: page table lock patch V15 [0/7]: overview" 
    Date:	Wed, 12 Jan 2005 17:47:29 +0100
To: "Barry K. Nathan" <barryn@pobox.com>

    On Tue, Jan 11, 2005 at 10:10:43PM -0800, Barry K. Nathan wrote:
    > On Tue, Jan 11, 2005 at 10:56:47PM -0200, Marcelo Tosatti wrote:
    > > Out of curiosity do you have a list of such syscalls?
    >
    > Not yet. I wasn't expecting to need the list quite this soon.
    >
    > > "usually" is the problem - you cannot be sure what syscalls unknown
    > > applications are using.
    > [snip]
    > > > And if you have programs that need it, you (or your vendor) can set the
    > > > config option accordingly.
    > >
    > > The possibility is that there might be unknown applications which use
    > > these "obsolete" system calls.
    >
    > True, but I would expect to see a strong correlation between the use of
    > "obsolete" syscalls and the use of "obsolete" libraries (libc4, libc5).
    > Until there's a list of obsolete syscalls, we can't say for sure,
    > though.
    >...

    The only interesting correlation are system calls that are _only_ used
    by libc4/libc5 applications.

    > > I personally dont like the idea of disabling "obsolete" system calls
    > > with config options, but it is useful for specialized applications to
    > > save memory.
    > >
    > > Are many users going to benefit from it?
    >
    > It's going to be hard to tell without full-blown code to examine and
    > test, but my hope is that it will be able to disable something
    > substantial for people who have completely abandoned libc4/libc5. And
    > that's many users.
    >
    > Even if the final patch is unable to benefit many users, perhaps the
    > process of creating that patch will still be worth it if it gives us a
    > better idea of which syscalls are being used and which ones aren't.

    Make such a patch, test it thoroughly and then send it here for review.

    It can't be guaranteed that your patch will be accepted, but as soon as
    you'll present the patch the discussion will become more flesh.

    > -Barry K. Nathan <barryn@pobox.com>

    cu
    Adrian 

    -- 
       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed
-
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/
  • Next message: Christoph Hellwig: "Re: page table lock patch V15 [0/7]: overview"

    Relevant Pages

    • Re: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)
      ... > The possibility is that there might be unknown applications which use ... Until there's a list of obsolete syscalls, we can't say for sure, ... Even if the final patch is unable to benefit many users, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Autotune swappiness01
      ... >> Attached is a patch designed to improve the behaviour of the swappiness knob ... >> conditions of heavy or sustained file stress while allowing applications to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 4/4] Hugetlb: Copy on Write support
      ... >> applications. ... The patch makes the following changes. ... >> which handles the COW fault by making the actual copy. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: move O_LARGEFILE forcing to filp_open()
      ... > Unfortunately, this will also cause problems for 32-bit emulation, where ... > 32 bit applications. ... Your patch is also necessary; ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [patch] removes redundant sys_delete_module()
      ... not implemented syscalls. ... This patch removes the redundant sys_delete_modulein module.c. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)