[lkml]   [2005]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] make uselib configurable (was Re: uselib() & 2.6.X?)
On Tue, Jan 11, 2005 at 05:18:16PM -0800, David Lang wrote:
> On Wed, 12 Jan 2005, Jesper Juhl wrote:
> >On Wed, 12 Jan 2005, Andries Brouwer wrote:
> >
> >>On Tue, Jan 11, 2005 at 02:51:27PM -0800, Barry K. Nathan wrote:
> >>>On Sat, Jan 08, 2005 at 10:46:19AM -0800, Linus Torvalds wrote:
> >>>>Another issue is likely that we should make the whole "uselib()"
> >>>>interfaces configurable. I don't think modern binaries use it (where
> >>>>"modern" probably means "compiled within the last 8 years" ;).
> >>
> >>libc 5.4.46 is from 1998-06-21 or so, glibc 2.0.5 from 1997-08-25 or so.
> >>
> >>>+config SYS_USELIB
> >>>+ bool "sys_uselib syscall support (needed for old binaries)"
> >>>+ ---help---
> >>>+ Many old binaries (e.g. dynamically linked a.out binaries, and
> >>>+ ELF binaries that are dynamically linked against libc5), require
> >>>+ the sys_uselib syscall. However, on the typical Linux system, this
> >>>+ code is just old cruft that no longer serves a purpose.
> >>>+
> >>>+ If you are unsure, say "N" if you care more about security and
> >>>+ trimming bloat, or say "Y" if you care more about compatibility
> >>>+ with old software. (If you will answer "Y" or "M" to BINFMT_AOUT,
> >>>+ below, you probably should answer "Y" here.)
> >>
> >>s/sys_uselib/uselib/
> >>The system call is uselib().
> >>
> >>Hmm - old cruft.. Why insult your users?
> >>I do not have source for Maple. And my xmaple binary works just fine.
> >>But it is a libc4 binary.
> >>
> >>You mean "on the typical recently installed Linux system, with nothing
> >>but the usual Linux utilities".
> >>
> >>People always claim that Linux is good in preserving binary compatibility.
> >>Don't know how true that was, but introducing such config options doesnt
> >>help.
> >>
> >>Let me also mutter about something else.
> >>In principle configuration options are evil. Nobody wants fifty thousand
> >>configuration options. But I see them multiply like ioctls.
> >>There should be a significant gain in having a config option.
> >>
> >I don't have much to say exceppt express my agreement. That is so very
> >true.
> >The less config options the user is presented with the better, and for
> >each config option there should be a very good reason. Very much agreed.
> >
> >
> >>Maybe some argue that there is a gain in security here. Perhaps.
> >>Or a gain in memory. It is negligible.
> >>I see mostly a loss.
> >>
> >>There are more ancient system calls, like old_stat and oldolduname.
> >>Do we want separate options for each system call that is obsoleted?
> >>
> >IMO, no, we do not.
> how about something like the embedded, experimental, and broken options.
> that way normal users can disable all of them at a stroke, people who need
> them can add them in.

Thats just not an option - you would have zillions of config options.

Moreover this is a system call, and the system call interface is one of the few
supposed to be stable. You shouldnt simply assume that "no one will ever use sys_uselib()" -
there might be programs out there who use it.

I agree with Andries.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:09    [from the cache]
©2003-2011 Jasper Spaans