[Xorg] debrix

[Jakub Piotr Cłapa]

Daniel Stone wrote:
> On Mon, Jun 28, 2004 at 05:42:15PM +0200, Jakub Piotr C?apa wrote:
> 
>>Daniel Stone wrote:
>>
>>>Nope. I guess the code has always just relied on it being a module. Try
>>>removing the two scanpci libraries from the Xorg linking in
>>>hw/xorg/Makefile.am, and changing hw/xorg/scanpci/Makefile.am:
>>>noinst_LIBRARIES = libscanpci.a libpcidata.a
>>>libscanpci_a_SOURCES = foo
>>>libpcidata_a_SOURCES = bar
>>>--
>>>to:
>>>lib_LTLIBRARIES = libscanpci.la libpcidata.la
>>>libscanpci_la_SOURCES = foo
>>>libpcidata_la_SOURCES = bar
>>
>>Tried. Works either way. When compiled in I just disable the probing 
>>stuff from xf86pciBus.c lines 1712-1730 + remove it from the baseModules 
>>and it works.
> 
> 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...
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?
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?

>>>Hrm. I have on idea without an extended look, and I have to start this
>>>stupid pastry again.
>>
>>It would help if I knew how to get vgahw symbols exported. (and why 
>>these are).
> 
> 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)

[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'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?

-- 
Regards,
Jakub Piotr Cłapa