sys_indirect() [LWN.net]

sys_indirect()

Posted Nov 21, 2007 12:06 UTC (Wed) by mjthayer (guest, #39183)
In reply to: sys_indirect() by nix
Parent article: sys_indirect()

But the point being that at some point it may be better to stop supporting old binaries
directly and move them to compatibility layers instead.  Currently I assume that binaries over
10 years old will still work in the unlikely event that everything else they need is still
available.  How long is forever though?

I suppose that the main difference from versioned symbols is that the compatibility layer
doesn't need to be inside the kernel, and doesn't even need to be installed on the machine if
it is not needed.

to post comments

sys_indirect()

Posted Nov 21, 2007 16:39 UTC (Wed) by nix (subscriber, #2304) [Link] (6 responses)

There's no need for that, though: glibc already *contains* code which looks at the
capabiliities of your machine and uses different syscall mechanisms depending on that (int80
versus vsyscall on x86/x86-64, for instance).

Should we run out of syscalls (on x86-64, we only have 2^32 minus a couple of hundred left!
such a harsh limit!) or should we decide the syscall table is too damn huge, then we could
always introduce another syscall mechanism and call it unconditionally from a new glibc.

The point being, if you can hack ld.so to preload things automatically, you can just as easily
modify libc.so to do the job itself in a much less ugly fashion :)

(of course the problem here remains the breaking of compatibility with all older glibcs: the
newer glibc doesn't need a major version bump, though. I suspect this is a step which the
kernel hackers will be very reluctant to take. It's happened on some arches, but they're all
relatively minor ones.)

sys_indirect()

Posted Nov 21, 2007 16:52 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

Right - as far as I know, the main reason that the syscall interface may never be changed is
old statically linked binaries, or at least binaries and libraries which do syscalls
themselves and not through libc.  That problem could be solved by hacking ld.so (as far as I
know, even statically linked binaries are loaded by ld.so, and if not something similar could
be found) but not by hacking libc.

sys_indirect()

Posted Nov 22, 2007 10:26 UTC (Thu) by nix (subscriber, #2304) [Link]

Statically linked binaries don't have a PT_INTERP header at all, so ld.so never gets involved.

ld.so and libc are tightly tied: if one is used, the other always will be as well. (It is I
think possible to dynamically link ld.so and statically link libc.a, but this is rare and
strange and you don't do it just by specifying -static at link time. It may well have
bitrotted.)

sys_indirect()

Posted Nov 21, 2007 18:26 UTC (Wed) by drag (guest, #31333) [Link] (3 responses)

It (transition from old and busted glibc to a imaginary shiny and sexy replacement-for-glibc)
could probably be handled in a similar fasion on how the X.org developers are handling the
transition from XCB to XLib. 

First they tried to go with XCL, which was a XLib compatability layer for XCB. It worked for
the most part, but a lot of the more oddball features of Xlib proved too difficult to
replication on top of XCB. 
http://xcb.freedesktop.org/History/

Now they are doing the Xlib/XCL approach, which is to have Xlib-guts being slowly ripped out
as applications gradually migrate to XCB, while having the Xlib actually running on top of
XCB. (or something like that) Using this approach they can acheive 100% binary compatability
and for programmers of applications/libraries using xlib they can start using XCB stuff right
away without a total rewrite. 

Also there is probably some answers to be found in the Linux-binary emulation features present
in other operating systems like FreeBSD, AIX, and Solaris.

sys_indirect()

Posted Nov 22, 2007 10:28 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

I wasn't aware there was any intent to have apps migrate en masse to XCB (does anyone know of
anything other than Xlib that uses XCB yet?). What is more likely to be useful is to have
*widget sets* migrate, as they already implement most of what Xlib does themselves, and don't
need most of the rest except for the raw comms stuff which XCB provides.

As far as I know the XCB-based Xlib is here to stay.

sys_indirect()

Posted Nov 22, 2007 22:36 UTC (Thu) by njs (subscriber, #40338) [Link] (1 responses)

GTK+ does use XCB in one or two obscure places, but most of it is still Xlib-based.  The big
advantage of Xlib-on-XCB is that it becomes possible to mix Xlib and XCB calls in the same
program, talking on the same X connection -- so you can have a gradual transition.  Aside from
toolkits themselves, interesting programs often have *some* direct calls to Xlib in addition
to all the ones that go through the toolkit, because toolkits don't expose everything.  (And
toolkits are explicitly architected to allow for this, e.g. there is a way to get an Xlib
Display* out of a GdkDisplay*.)  For some of those apps, being able to use a sane and
more-async-able API might well be valuable, and in general it is probably smart to use XCB in
new programs.

I have no idea what the equivalent for "libc migration" would be.  When would you want to use
two different libcs from the same program?  How would the compiler even know which version of
fork() you were trying to call?

sys_indirect()

Posted Nov 23, 2007 0:22 UTC (Fri) by nix (subscriber, #2304) [Link]

I suspect that the only way to `migrate' libcs would be a big bang with 
interface back-compatibility (which is, of course, exactly how glibc 
upgrades work). Nothing else works because of the presence of critical 
global data structures whose format must be understood by everything that 
accesses them (I'm thinking mostly of malloc() and free() here, but the 
exception unwinder is another example, which is why libgcc_s.so exists at 
all as opposed to just libgcc.a).