[Xorg] The big multiconsole nasty

[Adam Jackson]

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

On Tuesday 06 July 2004 11:17, John Dennis wrote:
> On Tue, 2004-07-06 at 07:45, Egbert Eich wrote:
> > When you are talking about kernel partition you tie yourself to a single
> > OS - not necessarily a single architecture. This is what worries me a
> > little bit.

I would disagree with this point.  Think int10; some OSes need to do it with 
an x86 emulator, but some can do it in vm86 mode directly.  All that matters 
with this API is that it exists and gets used.  How that API is implemented 
on various OSes will necessarily differ; but so what, we knew that, we 
already have that with X.  The kernel/user split is just a matter of whether 
a particular piece of code lives in the library or in the kernel, and really 
that's a compile-time flag; "Oh, WonderOS has an ioctl for passing video mode 
registers for the MegaCo PrettyPixel 7000, so I'll use that instead of 
mmap()ing the card and fiddling it myself".  The internal design of the 
library should be able to hide those sorts of details.

> <snip>
> 1) The XFree86 loader: One should assume the OS can dynamically load and
> link modules and that the OS knows more about this than the X server. In
> the past when very low level handling of object modules changed the X
> Server blew up spectacularly and required surgery to very arcane pieces
> of code none of which would have been necessary if the underlying system
> services had been used. I might add being able run a debugger on a
> running process would appear to be a novel concept ;-)

I have to agree.  Right now we've got both a libc thunk layer and a 
reimplementation of libdl in the server, all for a marginal (and I hear, 
rarely realized) gain in module portability.  I have trouble justifying that.  
I'm currently working at fixing the drivers so the libdl loader is usable 
again.

- - ajax
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA6tC4W4otUKDs0NMRAiJVAJ4jX3NOIzKv8PEYPq2JIaKWhhvg2gCbB/aR
jRtV5geTmCbcz32W7pVbfT8=
=nIUj
-----END PGP SIGNATURE-----