Dan Mick 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?...
It's distributed as a separate library on freedesktop.org, so would be
similar to ON pulling in the hal packages from freedesktop.org. It's
a user-space library, so wouldn't be something that would move into the
Linux kernel tree as far as I understand, while Solaris keeps both
kernek & user-space sources in the ON tree.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
