On Wed, Apr 1, 2009 at 2:33 AM, Dan Mick <dan.mick at sun.com> wrote:
>
>>> IMO the only fix around this would be, to move libpciaccess down into
>>> ON. Maybe, if that makes more sense / looks less strange. I mean
>>> libpciaccess of of general purpose/usability. It doesn't have much to
>>> do with Xorg itself. What do others think?
>>
>> That would simplify some coordination between prtconf & libpciaccess,
>> at the cost of making more work for X if we need a new libpciaccess
>> version for a future Xorg update. ? (I'd happily pay the cost if it
>> meant we got the kernel's PCI experts owning and fixing the code
>> though - it's still suffering in a number of areas from poor integration
>> with the Solaris kernel, which we've talked to them about, but not yet
>> completely solved.)
>>
>
> IMO it really belongs in ON, but to make that be smooth, it probably needs
> to move from Xorg into the Linux kernel too, no?...
>
> but yes, lspci for instance could certainly take good advantage of it.
lspci or scanpci ? The former is not integrated in any consolidation
AFAIK, but it comes as a part of pciutils, which has its own pci.ids
parsing code. The latter comes as a part of libpciaccess packaqge and
uses it already.
--
Regards,
Cyril
