[Xorg] The big multiconsole nasty
ajax at nwnk.net
Wed Jul 7 10:12:05 PDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
On Wednesday 07 July 2004 07:12, Egbert Eich wrote:
> Adam Jackson writes:
> > I would posit, however, that OS-independence in drivers is a false
> > economy. OSes are cheap, get a multi-boot rig and compile them all
> > directly. Or use a cross-compiler. From the perspective of the
> > graphics card manufacturer, you'd need to have the target platform
> > around for testing anyway if you're going to declare it a supported
> > platform.
> Well, do we believe the average developer will set up multiple
> OSes or set up cross compile environments to provide binaries
> for all supported OSes?
Who's your average developer? If it's an OSS dev, then binary compatibility
(almost always a hack) isn't relevant, because the user has source
compatibility, and they can build their own native modules. If your average
developer is a distribution release engineer, then they already have either
native or cross-compilation facilities for all their supported platforms.
I'd also point out that sourceforge (for example) has devel machines for many
of the common platforms, and that fd.o could easily set up cross-compilers...
The only people who might suffer - maybe - would be graphics companies
releasing closed drivers. But let's dissect that assumption. All the
MetroLink loader really buys you, over the libdl loader, is module
portability between platforms with different executable formats. No, really.
The libc wrapper (which I'm not really opposed to) already insulates you from
the system libc. You've already assumed a processor. The only free variable
left is whether you can open the module using the system libdl.
Which leads me to...
> What about the non-free OSes we support?
What about them? I was unaware that _any_ Unix vendor's X server used the
MetroLink loader, so it's not like we can use modules from Xsun with
xorg-solaris. If this assumption is false I'd be very interested to know.
Going the other direction, the only closed MetroLink modules that exist (that
I know of, again corrections welcomed) are for x86, and the only x86
platforms where we run directly on the hardware are: the BSDs, Linux,
Solaris/x86, old creaky SysV clones, and maybe OS/2. Of those, the ones that
are currently shipping overwhelmingly use ELF for their native module format.
So the ability to load non-native module formats doesn't buy you much,
because all the world is an ELF system.
Old systems can continue to use the old loader, and they'll be supported just
as well as they ever were. All of the code changes that have been made to
make the libdl modules work have been perfectly cross-compatible, meaning you
can build an old-style module with debrix-drivers-ati and it'll work just
The difference in building an old-style module versus a new-style one is
exactly equal to running ld instead of ar for the link stage. So - modulo
bugfixes  - every closed binary driver vendor can instantly ship native
modules just by adding three lines to the makefile. And vice versa;
old-style modules are so easy to generate that there's no excuse to not build
Which is fine, for the old decrepit platforms. But the MetroLink loader
causes real problems for modern systems.
> I also would like to call for a careful evaluation of the situation.
> Most of the people here belong to the Linux community so they probably
> don't care.
It's not that I don't care. If I didn't care I'd have nuked the old loader
from debrix already. I have thought it through, and I don't see any major
problems with making the native loader the default, but I've been wrong
before so I'm willing to keep the old loader around as a backup.
Of course, any driver supplier who refuses to supply old-style modules after
this transition is just being willfully perverse and hostile to their
customers, but that's not news or anything.
> However I would very much like to hear the opinions of those who use
> other OSes as they may be deprived of the possibility of loading binary
> only device drivers in the future.
Once the old loader is formally dead and buried, maybe, but again I don't see
that happening for a while yet. Deprecated, yes, but not removed.
- - ajax
 - Any driver vendors who need help detangling their drivers to work with
the libdl loader, _please_ let me know. It's nearly always a trivial fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the xorg