[Xorg] debrix

[Jakub Piotr Cłapa]

Daniel Stone wrote:
> 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.

Cool. :)

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

If we can return valid ModuleDescPtr for builtins that not a problem.

>>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 we can then no problem. Pitty I know too litle (yet) to make it work. 
You don't know of any papers covering the module loader stuff, do you? 
Only RTFSourceCode?

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

But it seems it doesn't really care which symbol I export. Event the 
most stupid ones (like xf86int10Addr in int10/generic.c) will force 
everything to go.

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

Ok. :)

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

I'm just not sure which is more clean - small binary + many modules or 
one big binary.

-- 
Regards,
Jakub Piotr Cłapa