On Sun, 14 Jul 2002, Derrick 'dman' Hudson wrote:
> | I don't understand the details, and it is probably worse when device
> | drivers are involved, but XFree86 doesn't use dlopen, but has its
> | own module loading system which doesn't even allow the driver direct
> | access to libc and other libraries (which does have the advantage
> | that the device driver *binaries* are operating system neutral*).
>
> Interesting. So the X folks created their own 'ld' and 'libc' for the
> the modules to use? Or do X drivers not need anything from libc in
> the first place?
XFree86 (an implementation of X) runs on a dozen unices, and some
none unix platforms (OS/2 is propably the most important, as cygwin
doesn't count) so has always had to have its own implementation of
bits of libc (and libm, possibly others). Not all platforms implement
all the necessary routines in libc, and not all in the same way
(consider the recent killall/pkill discussion).
When MetroWorks donated the module support (a replacement for ld in
some sense), libc calls which the drivers (and extensions, they can
be modules too) are allowed to make were wrapped, so that the module
calls a routine in the server, which then calls libc or a private
reimplementation.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
> | I don't understand the details, and it is probably worse when device
> | drivers are involved, but XFree86 doesn't use dlopen, but has its
> | own module loading system which doesn't even allow the driver direct
> | access to libc and other libraries (which does have the advantage
> | that the device driver *binaries* are operating system neutral*).
>
> Interesting. So the X folks created their own 'ld' and 'libc' for the
> the modules to use? Or do X drivers not need anything from libc in
> the first place?
XFree86 (an implementation of X) runs on a dozen unices, and some
none unix platforms (OS/2 is propably the most important, as cygwin
doesn't count) so has always had to have its own implementation of
bits of libc (and libm, possibly others). Not all platforms implement
all the necessary routines in libc, and not all in the same way
(consider the recent killall/pkill discussion).
When MetroWorks donated the module support (a replacement for ld in
some sense), libc calls which the drivers (and extensions, they can
be modules too) are allowed to make were wrapped, so that the module
calls a routine in the server, which then calls libc or a private
reimplementation.
--
Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge
A.C.Aitchison@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna