[PATCH] Implement Symbol-Based Video Driver Autoloading

[pcpa at mandriva.com.br]

Quoting David Nusinow <dnusinow at speakeasy.net>:

> Hi all,
>   The attached patch uses the symbols in the pci-reworked drivers to
> determine the correct video driver to load when none is specified by the
> config file. Before committing it though, I'd like some advice about
> certain aspects I'm not happy about:

  I did not look carefully at the other "pci-rework" code, pretty much just
your patch, but I think I know some of problems you may be having, or 
will find.
  I am trying to restart some work I did long ago that is somewhat related.


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

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

  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 believe this is a very important area of the X Server development, but
very few people working on it, and I am surprised, currently it actually
works :-) But a clean implementation/specification would be a sign of a
reliable/confiable system.

> Any other critiques and such are very welcome as well. Thanks!
>
> - David Nusinow

Paulo