[Xorg] The big multiconsole nasty

[Adam Jackson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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 [1] - 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 
them.

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

[1] - 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)

iD8DBQFA7C7lW4otUKDs0NMRAnbAAJ9ODUJQRrDsAZtgLoEZCqTUNeL3nACfXE5K
meOVcdOHgnsa/Ql9kI67e6s=
=N64i
-----END PGP SIGNATURE-----