[Xorg] The big multiconsole nasty

[Egbert Eich]

Adam Jackson writes:
 > -----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.

 Most users I know are not able to build their own native modules.
They have to rely on somebody to prebuild the modules for them.
A lot of these users will be happy to install a prebuild binary
module I email them when I provide the command line that copies
it to the right place.

 > 
 > 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...
This is not an elegant solution either.

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

I agree that today you get pretty far by assuming that systems are capable
of loading ELF binary modules. Therefore the argument for having a loader
that is capable of supporting other binary formats is not as strong as
it was years ago. 
The question remains if all OSes that can load ELF binaries can also create
them.

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

I'm not talking about vendor's X servers. The X.Org tree supports OSes
that have or don't have a native Xserver. Why one would like to replace
this one by X.Org's is another question, but if there wasn't a reason
the port would not exist.

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

Maybe we should do a poll which OSes we support (we certainly have supported
more than have been build and tested recently) and see which binary formats
exist there. I acknowledge that this may be much less an issue than a few
years ago.
And you may very well be true it mostly matters on x86 - there the module
loader has been stable for a long time.

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

On x86 it's true. On most other platforms you will have to produce PIC
code - which cannot be handled by the old loader.

 > 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'm aware of this as I ported the loader to AMD64.

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

Fine. That's definitely a wise decision.

Egbert.