sys_indirect() [LWN.net]

sys_indirect()

Posted Nov 21, 2007 18:26 UTC (Wed) by drag (guest, #31333)
In reply to: sys_indirect() by nix
Parent article: sys_indirect()

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.

to post comments

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).