| |||||||||||||
sys_indirect()sys_indirect()Posted Nov 21, 2007 18:26 UTC (Wed) by drag (subscriber, #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.
(Log in to post comments)
sys_indirect() Posted Nov 22, 2007 10:28 UTC (Thu) by nix (subscriber, #2304) [Link] 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 (guest, #40338) [Link] 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).
|
|||||||||||||