This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Le 06/02/2013 01:55, Samuel Thibault a écrit :
> Jeff Squyres (jsquyres), le Wed 06 Feb 2013 01:41:21 +0100, a écrit :
>> On Feb 5, 2013, at 3:50 PM, Samuel Thibault <samuel.thibault_at_[hidden]> wrote:
>>> Jeff Squyres (jsquyres), le Tue 05 Feb 2013 22:52:01 +0100, a écrit :
>>>> It was just pointed out to me that libpci is licensed under the GPL (not the LGPL).
>>> I'm told that we could use libpciaccess instead, which is BSD.
>> That would be great -- is it easily available?
> Yes. I've made a quick port, it does work. libpciaccess is however a
> bit buggy (it doesn't find my nvidia card for instance), and does not
> support finding capabilities (but we can do this by hand).
Hmmm, all this licensing mess is likely my fault. I don't remember if I
checked the pciutils licence when I started the port...
I looked at pciaccess a couple years ago because pciutils wasn't
available on darwin. The early conclusion was that it didn't support
bridges, but that doesn't seem true: your patch finds everything on my
laptop (Intel based including link speed). pcidev->name isn't set but
that looks easy to fix.
My experience with Xorg package maintenance didn't make me trust that
sort of upstream much :/ But I may still have commit access there if we
need to fix some bugs :)
Any idea why it doesn't find your nvidia card? I didn't find anything in
google except some ugly Xorg-related problems. I hop it's not related to
the drm kernel drivers doing some initialization before libpciaccess can
find the card.
By the way, the contamination should be limited to the libpci plugin
when plugins are enabled.