On Jun 8, 2010, at 2:51 PM, Mike Travis wrote:
Mikhail Gusarov wrote:
Twas brillig at 14:26:32 08.06.2010 UTC-07 when [email protected]
did gyre and gimble:
RB> I'd like advice/opinions on which of these might be the most
eagerly
RB> embraced (or at any rate, least vigorously opposed :-) ), or
whether
RB> there's a better idea I've overlooked.
The Right Thing that immediately comes to mind is fixing libpciaccess
internals to be able to read data from saner (indexed,
string-compressed, with common strings merged for different PCI ids)
file format to avoid problem with linear search altogether. Given
simplicity of data format it should be nearly trivial task.
Another thought would be to cache the strings related to the devices
attached to the system and save them some place. Only need to go to
big database if new device is attached.
Yup, I've thought about variations on this theme. It works well enough
for Chrome OS, where the cache file could be generated once when the
system software was installed (i.e. at manufacturing time), but as a
general purpose solution usable to any Linux distro, maintaining the
cache as up-to-date if a user upgraded system hardware would be a bit
more work.
Assuming we declare that generating and maintaing the cache file is
SEP, there are two ways to go about it:
* Enhance libpciaccess to search a longer list of files, so that
the cache file could be checked ahead of the full index.
Currently,
libpciaccess looks for "pci.ids.gz" and then "pci.ids" in a
directory
that's selected at configure time. The change would be to have two
configured directories, and search for four files.
* Just add the option to X to specify the "pci.ids" file on the
command line, and pass the cache file (or the full index) to
the X server.
-- jrb
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
