[PATCH] Implement Symbol-Based Video Driver Autoloading

[David Nusinow]

Hi Paulo,

On Thu, Nov 15, 2007 at 03:47:21AM -0200, pcpa at mandriva.com.br wrote:
> Quoting David Nusinow <dnusinow at speakeasy.net>:
>> 1) I don't use the loader at all, I just dlopen, dlsym, and dlclose
>>    manually rather than use the loader's functions that do the same. Since
>>    we're all dlloader now, this shouldn't be an issue, and this approach
>>    avoids heavyweight things like logging each time we check a module, but
>>    I'd like to know if I should try to use the loader itself somehow
>>    instead.
>
>  I believe it would be better to use the loader, and/or adapt it.
> There isn't much documentation about it. Probably your best bet is
> hw/xfree86/doc/sgml/DESIGN.sgml that may be outdated, and the source code
> itself that probably doesn't work anymore with anything other than dlopen(),
> etc. The loader has several useful features, and duplicating functionality
> everywhere isn't wise; same for parsing, reading and writing configuration
> files (i.e. adapt or completely remove/replace libxf86config).

The loader is pretty clear these days thanks to ajax's work. My initial
attempt at the patch actually did use the loader to load and unload the
module, but in unloading the module I ran in to a bug where I tried to
re-load driver later and found that the server thought the driver was still
loaded. I could fix it, but it'd still leave the issue of lots of
heavyweight logging that's probably useless. I could create quiet versions
of the loader functions, but I doubt they'd be used for anything but this
feature.

>> 2) Related to 1, I pull out the DriverRect manually by appropriately
>>    mangling the module name, but since the server does this elsewhere I
>>    feel like I should be able to just call a function available elsewhere
>>    to do this. Is there an easy way to do this that I've missed, or should
>>    I try abstracting it out from other parts of the server so I can use it
>>    here?
>
>  This could be yet another chance to fix some of the mess :-) For example,
> have proper and well defined initialization functions, and what can be done
> at what level. A standard way to query things like available options, maybe
> even without the need to load the driver/module. Currently only video drivers
> have the AvailableOptions(int, int) call, and a few input modules. But the
> xf86ModuleInfo and xf86AddModuleInfo() is more of a hack, and only
> implemented/used  by a few drivers, but provides a way to get a pointer
> to an OptionInfoPtr listing available options.
>  It should be possible to query and have documentation for all available
> options (including core X Server options and builtin modules). Several years
> ago I added the xf86ModuleInfo interface and wrote some text about an almost
> complete reimplementation of options parsing and definition; in a way that
> would "force" developers to document it (or cheat :-)), as it would not 
> compile
> without up to date documentation. But I did not get any feedback, and I did 
> not
> want to break the ABI gratuitously, so I never implemented it...
>  At some time there was also an pseudo api to send/receive strings to/from a
> module. A properly specified standard would be very desirable, so that every
> vendor doesn't need to reinvent the wheel, to create an interface for
> configuration tools to comunicate with the "running" driver/module, like
> NVidia Display Settings tool for the nvidia driver, and some others like
> s3utility from the drivers available at www.viaarena.com.

All this is sensible, although pretty far off the mark from what I'm
interested in addressing right now. Loading the right driver based on the
hardware should be something the X server is capable of. Whether this
involves asking each driver, hal, or something else, it should be a fairly
easy thing to do at this stage. Re-architecting the server/driver interface
to permit arbitrary exchange is a little outside my area, and I'd want to
defer to driver maintainers on that one.

>  Oh, and, I am not sure, but I believe, drivers should not have full access
> to X Server symbols. But since they all run in the same process, implementing
> some kind of "ioctl like interface" probably would be pointless. At least a
> fix for xf86ansic would also be desirable, i.e. not have some modules linked
> to use directly libc functions, and others to use the xf86<libc-symbol>,
> and/or mixing them. For open source drivers, this probably isn't a problem,
> but full access to closed source drivers should not be available, i.e. a video
> driver connecting to the internet, reading/writing from/to random files,
> starting threads, messing with signals or kernel modules...

I'm not sure this is worth doing. Having the drivers as part of the running
process works fine for things like the linux kernel. And as more of the
drivers move in to the kernel itself, I think the arguments for doing this
become less and less worthwhile.

 - David Nusinow