[PATCH] Implement Symbol-Based Video Driver Autoloading

[pcpa at mandriva.com.br]

Quoting David Nusinow <dnusinow at speakeasy.net>:

> Hi Paulo,

  Hi :-)

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

  Maybe the module is doing something like adding an extension or anything
else that should not be done in the "setupProc", or is triggering some bug
when loading sub modules or dependencies. I think several things cannot be
properly unloaded, or would require significant amount of work to handle
properly.

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

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

  How would you handle hardware that can be managed by different drivers?
This can go as bad as one driver being good at one thing and another being
good at another (or one good at a specific chip revision and bad at another),
or worse, newer versions of a driver not working like a previous version, but
currently there aren't different version, neither a convention for naming
i.e. zzz_drv.so.0, zzz_drv.so.1, etc.

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

  I don't disagree, but it can cause future problems also, if a module tries
to access a symbol that is not defined in the server. But this would probably
only be a problem for binary drivers if a distro chooses to compile the server
withot some feature the module wants.
  And I can tell you that several modules are very "intrusive" in what they
access.
  Other possible problems are changes in internal data structures. Most such
structures are defined in the headers installed at /usr/include/xorg; also,
maybe some of those would be better installed in a sub directory, i.e.
/usr/include/xorg/{dix,fb,render,mi}...
  I will become afraid when video drivers start moving to the kernel, imagine
finding out that your missing black screen contents are stored in random
places in the filesystem, or any kind of "stop the world" until this card
register gives the expected value :-)


> - David Nusinow

Paulo