[Xorg] debrix

[Daniel Stone]

On Tue, Jun 29, 2004 at 03:27:55AM +0200, Jakub Piotr C?apa wrote:
> Daniel Stone wrote:
> >Hm, cool.
> 
> I've patched [1] the ati driver not to load builtin modules but I'm 
> afraid it's a hack more than a fix...

THe long-term mix is to have the loader just return for built-ins.

> Is it possible for someone to load a module which doesn't know about our 
> builtins? For example a binary driver or sth like that?

It might be able to load binary modules with the XFree86-ELF loader
(elfloader.c). Balance of probabilities, no: it didn't even load the
fbdev module for a while. Because we're doing so much stuff, it's really
a matter of make sweeping change, see just how much stuff you broke,
unbreak for the specific cases you encounter, realise the damage is
greater than you thought, unbreak for the specific cases, move on to the
next TODO item, rinse, repeat.

> Maybe I'm panicking and we can be sure that everybody writing anything 
> having any chances to work as a debrix module will know what we have 
> statically linked (and we will not change our minds in this matter).
> If not we need a way to allow inserting modules iff (if and only if) 
> they are not built into the core. Sadly I fail to see a way to do it. If 
> LoadModule is to succed it should return a cool brand new ModuleDescPtr. 
> Can we make a valid one for builtin modules?

Sure we can.

> >If function foosym needs to be exported, you need to add:
> >SYMFUNC(foosym);
> >to hw/xorg/loader/xf86sym.c; if it's a variable:
> >SYMVAR(foosym);
> 
> It's almost like that. After playing with this it seems you need to 
> explicitly SYMFUNC only one symbol from each object file to export them 
> all. Or sth. similar - I added vgaHWInit and got them all. ;)
> I have tried to add all needed exports but stopped in the middle and 
> went to sleep. My current patch is available [2]. (also adds some files 
> to int10 because it had missing symbols whan linking the main binary)

Hm, interesting ... or not.

That makes sense, because vgaHWInit will make the module pointer, which
will reference almost every other vgahw symbol.

> [1] 
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-modules.patch?rev=1.1
> [2] 
> http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/debrix-driver-ati-modules.patch?rev=1.2

I'll look at these later: I'm still trying to deal with the fact that I
just woke up, it's 4:48pm, and I have a billion things to do today.

> I'm starting to doubt if statically linking everything was a good 
> idea... Maybe it would be easier to expose needed variables with 
> functions? Are there any other reasons you merged everything into one 
> binary?

Cleanliness is next to godliness. Also, the variable interdependency
thing: the nv driver doesn't really work otherwise. Ditto fbdev.

-- 
Daniel Stone                                            <daniel at freedesktop.org>
freedesktop.org: powering your desktop                http://www.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20040629/95a07e2e/attachment.pgp>