| Message ID | 1378302428-19758-1-git-send-email-teg@jklm.no |
|---|---|
| State | Not Applicable |
| Headers | show |
Hello! First of all: Sorry for not replying to the first mail. I do not follow linux-pci too much these days (or, I do that in big batches). > This lets you select hwdb support at compile time. > > hwdb is an efficient hardware database shipped with recent versions of udev. > It contains among other sources pci.ids so querying hwdb rather than reading > pci.ids directly should give the same result. > > Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb > as the only source of this information, which this patch allows. Generally, I will be glad to include hwdb support in libpci. There is a couple of details I am concerned with: > + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then > + HWDB=yes > + else > + HWDB=no > + fi Does this make sense? Does every version of libudev support hwdb? > @@ -86,8 +91,58 @@ char > *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2, int id3, int id4) > { > struct id_entry *n, *best; > - u32 id12 = id_pair(id1, id2); > - u32 id34 = id_pair(id3, id4); > + u32 id12, id34; > + > +#ifdef PCI_HAVE_HWDB > + if (!(flags & PCI_LOOKUP_SKIP_LOCAL)) > + { As you wrote it, hwdb has always priority over pci.ids (unless local lookup is disabled). As a user, I would expect that pci.ids (being a part of the pciutils) is the primary source of data and other sources (network lookups, hwdb) are used only if pci.ids do not match or if explicitly requested. Have a nice fortnight
On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares <mj@ucw.cz> wrote: > Hello! > > First of all: Sorry for not replying to the first mail. I do not follow > linux-pci too much these days (or, I do that in big batches). No problem, I guessed as much. >> This lets you select hwdb support at compile time. >> >> hwdb is an efficient hardware database shipped with recent versions of udev. >> It contains among other sources pci.ids so querying hwdb rather than reading >> pci.ids directly should give the same result. >> >> Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb >> as the only source of this information, which this patch allows. > > Generally, I will be glad to include hwdb support in libpci. Great. >> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then >> + HWDB=yes >> + else >> + HWDB=no >> + fi > > Does this make sense? Does every version of libudev support hwdb? Good point. I'll replace it with a pkg-config call, is that acceptable? >> @@ -86,8 +91,58 @@ char >> *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2, int id3, int id4) >> { >> struct id_entry *n, *best; >> - u32 id12 = id_pair(id1, id2); >> - u32 id34 = id_pair(id3, id4); >> + u32 id12, id34; >> + >> +#ifdef PCI_HAVE_HWDB >> + if (!(flags & PCI_LOOKUP_SKIP_LOCAL)) >> + { > > As you wrote it, hwdb has always priority over pci.ids (unless local lookup is > disabled). As a user, I would expect that pci.ids (being a part of the pciutils) > is the primary source of data and other sources (network lookups, hwdb) are > used only if pci.ids do not match or if explicitly requested. Hm, this was actually intentional. The reason being that I'd like to avoid reading in the pci.ids db in the common case, as using the hwdb should be much more efficient (it is most likely already in memory and lookup is constant time), and also we (at the distro level) want to move away from the {usb,pci}.ids and rather default to hwdb everywhere. My original intention was to make hwdb a replacement for pci.ids, but I ended up going the less invasive route, would making it a replacement be more acceptable? If not, I'll just swap around the priority, not a problem. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen <teg@jklm.no> wrote: > On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares <mj@ucw.cz> wrote: >> Hello! >> >> First of all: Sorry for not replying to the first mail. I do not follow >> linux-pci too much these days (or, I do that in big batches). > > No problem, I guessed as much. > >>> This lets you select hwdb support at compile time. >>> >>> hwdb is an efficient hardware database shipped with recent versions of udev. >>> It contains among other sources pci.ids so querying hwdb rather than reading >>> pci.ids directly should give the same result. >>> >>> Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb >>> as the only source of this information, which this patch allows. >> >> Generally, I will be glad to include hwdb support in libpci. > > Great. > >>> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then >>> + HWDB=yes >>> + else >>> + HWDB=no >>> + fi >> >> Does this make sense? Does every version of libudev support hwdb? > > Good point. I'll replace it with a pkg-config call, is that acceptable? > >>> @@ -86,8 +91,58 @@ char >>> *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2, int id3, int id4) >>> { >>> struct id_entry *n, *best; >>> - u32 id12 = id_pair(id1, id2); >>> - u32 id34 = id_pair(id3, id4); >>> + u32 id12, id34; >>> + >>> +#ifdef PCI_HAVE_HWDB >>> + if (!(flags & PCI_LOOKUP_SKIP_LOCAL)) >>> + { >> >> As you wrote it, hwdb has always priority over pci.ids (unless local lookup is >> disabled). As a user, I would expect that pci.ids (being a part of the pciutils) >> is the primary source of data and other sources (network lookups, hwdb) are >> used only if pci.ids do not match or if explicitly requested. > > Hm, this was actually intentional. The reason being that I'd like to > avoid reading in the pci.ids db in the common case, as using the hwdb > should be much more efficient (it is most likely already in memory and > lookup is constant time), and also we (at the distro level) want to > move away from the {usb,pci}.ids and rather default to hwdb > everywhere. > > My original intention was to make hwdb a replacement for pci.ids, but > I ended up going the less invasive route, would making it a > replacement be more acceptable? > > If not, I'll just swap around the priority, not a problem. Hi Martin, Any comments on the above before I resubmit? Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Sep 13, 2013 at 1:08 PM, Tom Gundersen <teg@jklm.no> wrote: > On Wed, Sep 4, 2013 at 4:59 PM, Tom Gundersen <teg@jklm.no> wrote: >> On Wed, Sep 4, 2013 at 3:57 PM, Martin Mares <mj@ucw.cz> wrote: >>> Hello! >>> >>> First of all: Sorry for not replying to the first mail. I do not follow >>> linux-pci too much these days (or, I do that in big batches). >> >> No problem, I guessed as much. >> >>>> This lets you select hwdb support at compile time. >>>> >>>> hwdb is an efficient hardware database shipped with recent versions of udev. >>>> It contains among other sources pci.ids so querying hwdb rather than reading >>>> pci.ids directly should give the same result. >>>> >>>> Ideally Linux distros using udev could stop shipping pci.ids, but use hwdb >>>> as the only source of this information, which this patch allows. >>> >>> Generally, I will be glad to include hwdb support in libpci. >> >> Great. >> >>>> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then >>>> + HWDB=yes >>>> + else >>>> + HWDB=no >>>> + fi >>> >>> Does this make sense? Does every version of libudev support hwdb? >> >> Good point. I'll replace it with a pkg-config call, is that acceptable? >> >>>> @@ -86,8 +91,58 @@ char >>>> *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2, int id3, int id4) >>>> { >>>> struct id_entry *n, *best; >>>> - u32 id12 = id_pair(id1, id2); >>>> - u32 id34 = id_pair(id3, id4); >>>> + u32 id12, id34; >>>> + >>>> +#ifdef PCI_HAVE_HWDB >>>> + if (!(flags & PCI_LOOKUP_SKIP_LOCAL)) >>>> + { >>> >>> As you wrote it, hwdb has always priority over pci.ids (unless local lookup is >>> disabled). As a user, I would expect that pci.ids (being a part of the pciutils) >>> is the primary source of data and other sources (network lookups, hwdb) are >>> used only if pci.ids do not match or if explicitly requested. >> >> Hm, this was actually intentional. The reason being that I'd like to >> avoid reading in the pci.ids db in the common case, as using the hwdb >> should be much more efficient (it is most likely already in memory and >> lookup is constant time), and also we (at the distro level) want to >> move away from the {usb,pci}.ids and rather default to hwdb >> everywhere. >> >> My original intention was to make hwdb a replacement for pci.ids, but >> I ended up going the less invasive route, would making it a >> replacement be more acceptable? >> >> If not, I'll just swap around the priority, not a problem. > > Hi Martin, > > Any comments on the above before I resubmit? Ping? -t -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello and sorry for the delay, > >> + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then > >> + HWDB=yes > >> + else > >> + HWDB=no > >> + fi > > > > Does this make sense? Does every version of libudev support hwdb? > > Good point. I'll replace it with a pkg-config call, is that acceptable? Sure. > > As you wrote it, hwdb has always priority over pci.ids (unless local lookup is > > disabled). As a user, I would expect that pci.ids (being a part of the pciutils) > > is the primary source of data and other sources (network lookups, hwdb) are > > used only if pci.ids do not match or if explicitly requested. > > Hm, this was actually intentional. The reason being that I'd like to > avoid reading in the pci.ids db in the common case, as using the hwdb > should be much more efficient (it is most likely already in memory and > lookup is constant time), and also we (at the distro level) want to > move away from the {usb,pci}.ids and rather default to hwdb > everywhere. > > My original intention was to make hwdb a replacement for pci.ids, but > I ended up going the less invasive route, would making it a > replacement be more acceptable? Before establishing priorities, I want to understand several things: First of all, how is the hwdb populated? I really don't want lspci users to be stuck with an obsolete list of PCI devices. Currently, the user can easily run update-pciids to get a fresh copy of pci.ids, or to use the DNS-based protocol to resolve unknown devices on the fly. Does hwdb provide anything like that? From a brief examination of systemd-208, I understand that the PCI part of the hwdb is generated by systemd maintainers calling ids-update.pl, which not even a part of the systemd tarball. Is it expected that the only way how to get a recent hwdb is to update systemd packages? Also, did you consider the opposite, that is making hwdb call libpci to resolve PCI IDs? What are the downsides? Have a nice fortnight
On Sun, Dec 15, 2013 at 1:23 AM, Tom Gundersen <teg@jklm.no> wrote: >> Also, did you consider the opposite, that is making hwdb call libpci >> to resolve PCI IDs? What are the downsides? > > Well, part of the reason for introducing the hwdb was to avoid libpci for > performance reasons (I added Kay in cc who can correct me if I'm wrong): > Firstly we don't want to parse the ids file at runtime, and secondly we want > the constant time lookup time that hwdb gives. Due to the increased > performance we are now able to tag (in the udev database) all devices with > the pciids info, before we could only do this for selected devices. A result > of this is that this info is available 'for free' for any app that uses > libudev. Hwdb is an indexed database which can be queried without any measurable cost. It also carries more information than the textual strings, and this data is needed during early boot, so we need hwdb anyway. Libpci and its linear search through megabytes of text files for evey new query is too inefficient, that we cannot afford to use it during early bootup. It was the largest hit left in bootup profiling on machines booting userspace in the sub-1-second range on common machines. It was probably never meant to provide efficient queries, but it's the reason we can never use it during early boot. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Kay, > Libpci and its linear search through megabytes of text files for evey > new query is too inefficient, that we cannot afford to use it during > early bootup. It was the largest hit left in bootup profiling on > machines booting userspace in the sub-1-second range on common > machines. It was probably never meant to provide efficient queries, > but it's the reason we can never use it during early boot. I do not know what you are speaking about -- libpci definitely does not perform linear scans on pci.ids. It builds a hash table from pci.ids on the first query and and all subsequent queries are O(1) on average. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Dec 15, 2013 at 10:18 AM, Martin Mares <mj@ucw.cz> wrote: > Hello Kay, > >> Libpci and its linear search through megabytes of text files for evey >> new query is too inefficient, that we cannot afford to use it during >> early bootup. It was the largest hit left in bootup profiling on >> machines booting userspace in the sub-1-second range on common >> machines. It was probably never meant to provide efficient queries, >> but it's the reason we can never use it during early boot. > > I do not know what you are speaking about -- libpci definitely does > not perform linear scans on pci.ids. It builds a hash table from pci.ids > on the first query and and all subsequent queries are O(1) on average. It does that per process doing that, and that's the problem for how udev works/worked. The binary hwdb is on-disk and can be mmaped, and there is no difference between initialization, first, or subsequent queries. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello! > It does that per process doing that, and that's the problem for how > udev works/worked. The binary hwdb is on-disk and can be mmaped, and > there is no difference between initialization, first, or subsequent > queries. OK, point taken. I see that a mechanism for fast lookup of hardware identification data is needed. However, why should such a mechanism depend on udev, systemd, or Linux in general? What I would really like to have is a universal library for HW lookup, independent of anything else and widely portable. All the hardware data would be provided by other packages -- pci.ids, usb.ids, kernel modules, etc. -- and compiled to a binary format available for instant queries. Do I miss anything? Have a nice fortnight
On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares <mj@ucw.cz> wrote: >> It does that per process doing that, and that's the problem for how >> udev works/worked. The binary hwdb is on-disk and can be mmaped, and >> there is no difference between initialization, first, or subsequent >> queries. > > OK, point taken. > > I see that a mechanism for fast lookup of hardware identification data > is needed. However, why should such a mechanism depend on udev, systemd, > or Linux in general? > > What I would really like to have is a universal library for HW lookup, > independent of anything else and widely portable. All the hardware data > would be provided by other packages -- pci.ids, usb.ids, kernel modules, > etc. -- and compiled to a binary format available for instant queries. Yeah, that's what udev's hwdb is for us now. For the textual strings, it seems relatively easy to commit to a reasonable stable format, but I doubt that text strings alone would justify supporting a binary format to compile to. I wouldn't want to commit to cross-platform stability for other device properties we use, or things which will end up in the hwdb. It's hard enough already to coordinate the development across Linux distributions, and generic cross-platform device-management metadata maintenance doesn't sound too promising or an easy goal to me. Some data of hwdb is entirely Linux and Linux kernel device specific. The hwdb query string to lookup the binary radix tree in the hwdb file is just the Linux kernel modalias strings, and they are directly passed as queries to hwdb. Other platforms could do the same thing, sure, but I'm not sure this really makes too much sense. > Do I miss anything? No, you didn't. It's just that we develop for and work with Linux only, and this is really hard enough already. :) I personally never think about other platforms because I don't really know/care about or use them; and hwdb was just a tiny and not important enough piece of the problem we need to solve, so it became part of udev. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Martin, On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares <mj@ucw.cz> wrote: > I see that a mechanism for fast lookup of hardware identification data > is needed. However, why should such a mechanism depend on udev, systemd, > or Linux in general? > > What I would really like to have is a universal library for HW lookup, > independent of anything else and widely portable. All the hardware data > would be provided by other packages -- pci.ids, usb.ids, kernel modules, > etc. -- and compiled to a binary format available for instant queries. I'd like to reach an agreement on this patch, so I'll resend it with the changes we agreed on so far. Please let me know if further changes are needed. If I understand correctly, you are ok with the functionality hwdb provides, but would have preferred an OS-agnostic solution. However, as no such solution currently exist, and the patch adding hwdb support is pretty minimal and self-contained, would you be happy taking that for now, and rather revisit the topic if and when a generic solution appears? FWIW, I made the analogous change to lsusb some time ago [0], so would be cool to get this all done. Cheers, Tom [0]: <https://github.com/gregkh/usbutils/commit/c6282a7a0e20fbb9c56837f055843635a43ba8b4> -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Ping? On Wed, Jan 29, 2014 at 5:13 PM, Tom Gundersen <teg@jklm.no> wrote: > Ping? > > On 30 Dec 2013 19:53, "Tom Gundersen" <teg@jklm.no> wrote: >> >> Hi Martin, >> >> On Sun, Dec 15, 2013 at 12:33 PM, Martin Mares <mj@ucw.cz> wrote: >> > I see that a mechanism for fast lookup of hardware identification data >> > is needed. However, why should such a mechanism depend on udev, systemd, >> > or Linux in general? >> > >> > What I would really like to have is a universal library for HW lookup, >> > independent of anything else and widely portable. All the hardware data >> > would be provided by other packages -- pci.ids, usb.ids, kernel modules, >> > etc. -- and compiled to a binary format available for instant queries. >> >> I'd like to reach an agreement on this patch, so I'll resend it with >> the changes we agreed on so far. Please let me know if further changes >> are needed. >> >> If I understand correctly, you are ok with the functionality hwdb >> provides, but would have preferred an OS-agnostic solution. However, >> as no such solution currently exist, and the patch adding hwdb support >> is pretty minimal and self-contained, would you be happy taking that >> for now, and rather revisit the topic if and when a generic solution >> appears? >> >> FWIW, I made the analogous change to lsusb some time ago [0], so would >> be cool to get this all done. >> >> Cheers, >> >> Tom >> >> [0]: >> <https://github.com/gregkh/usbutils/commit/c6282a7a0e20fbb9c56837f055843635a43ba8b4> -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi!
> Ping?
Sorry for the delay, I was alternatingly ill and overloaded with other stuff...
As I said before, I do not like the current implementation of hwdb much (it's
too much tied to Linux, and hardware description strings, originally intended
for internal use between the kernel and its modules, are far from a nice API).
I would prefer a more general HW identification library and I am willing to
write it, but I have to admit that with my current load, it will be hardly
finished before this summer.
I will merge your patches. It's better to have the current hwdb than nothing.
Have a nice fortnight
On Wed, Feb 12, 2014 at 8:58 PM, Martin Mares <mj@ucw.cz> wrote: > Hi! > >> Ping? > > Sorry for the delay, I was alternatingly ill and overloaded with other stuff... No worries. I hope you are better now. > As I said before, I do not like the current implementation of hwdb much (it's > too much tied to Linux, and hardware description strings, originally intended > for internal use between the kernel and its modules, are far from a nice API). > > I would prefer a more general HW identification library and I am willing to > write it, but I have to admit that with my current load, it will be hardly > finished before this summer. Looking forward to seeing that. > I will merge your patches. It's better to have the current hwdb than nothing. Thanks! Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tom!
The support for hwdb has finally landed in mainline pciutils.
I have modified your patch to bring it closer to the rest of device
naming logic. Namely:
• The interface to HWDB now lives in a separate source file
lib/names-hwdb.c. It is called from the main entry point
to the name resolver (lib/names.c).
• Resolved names are cached in the hash table and they participate
in the system of priorities. They have lower priority than pci.ids,
but higher than remote lookups via DNS. (Therefore if a distro
decides not to ship pci.ids, hwdb is used exclusively for all
local lookups.)
• There is a flag to suppress the use of HWDB (PCI_LOOKUP_NO_HWDB)
and also a configuration parameter for the same (hwdb.disable).
Aside of the README, everything should be ready for a public release.
Could you please verify that it still works for you?
Have a nice fortnight
Hi Martin, On Sat, Nov 1, 2014 at 6:51 PM, Martin Mares <mj@ucw.cz> wrote: > The support for hwdb has finally landed in mainline pciutils. > > I have modified your patch to bring it closer to the rest of device > naming logic. Namely: Great! Thanks for merging this, and for working on it. > Aside of the README, everything should be ready for a public release. > Could you please verify that it still works for you? I can verify that it still works as expected, so it is good to go as far as I'm concerned. Cheers, Tom -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/configure b/lib/configure index 27388bc..bb9a983 100755 --- a/lib/configure +++ b/lib/configure @@ -141,6 +141,23 @@ esac echo >>$c '#define PCI_HAVE_PM_DUMP' echo " dump" +echo_n "Checking for udev hwdb support... " +if [ "$HWDB" = yes -o "$HWDB" = no ] ; then + echo "$HWDB (set manually)" +else + if [ -f /usr/include/libudev.h -o -f /usr/local/include/libudev.h ] ; then + HWDB=yes + else + HWDB=no + fi + echo "$HWDB (auto-detected)" +fi +if [ "$HWDB" = yes ] ; then + echo >>$c '#define PCI_HAVE_HWDB' + echo >>$m 'LIBUDEV=-ludev' + echo >>$m 'WITH_LIBS+=$(LIBUDEV)' +fi + echo_n "Checking for zlib support... " if [ "$ZLIB" = yes -o "$ZLIB" = no ] ; then echo "$ZLIB (set manually)" diff --git a/lib/names-hash.c b/lib/names-hash.c index 33f3c11..9661d03 100644 --- a/lib/names-hash.c +++ b/lib/names-hash.c @@ -11,6 +11,11 @@ #include "internal.h" #include "names.h" +#ifdef PCI_HAVE_HWDB +#include <libudev.h> +#include <stdio.h> +#endif + struct id_bucket { struct id_bucket *next; unsigned int full; @@ -86,8 +91,58 @@ char *pci_id_lookup(struct pci_access *a, int flags, int cat, int id1, int id2, int id3, int id4) { struct id_entry *n, *best; - u32 id12 = id_pair(id1, id2); - u32 id34 = id_pair(id3, id4); + u32 id12, id34; + +#ifdef PCI_HAVE_HWDB + if (!(flags & PCI_LOOKUP_SKIP_LOCAL)) + { + char modalias[64]; + const char *key = NULL; + struct udev *udev = udev_new(); + struct udev_hwdb *hwdb = udev_hwdb_new(udev); + struct udev_list_entry *entry; + + switch(cat) + { + case ID_VENDOR: + sprintf(modalias, "pci:v%08X*", id1); + key = "ID_VENDOR_FROM_DATABASE"; + break; + case ID_DEVICE: + sprintf(modalias, "pci:v%08Xd%08X*", id1, id2); + key = "ID_MODEL_FROM_DATABASE"; + break; + case ID_SUBSYSTEM: + sprintf(modalias, "pci:v%08Xd%08Xsv%08Xsd%08X*", id1, id2, id3, id4); + key = "ID_MODEL_FROM_DATABASE"; + break; + case ID_GEN_SUBSYSTEM: + sprintf(modalias, "pci:v*d*sv%08Xsd%08X*", id1, id2); + key = "ID_MODEL_FROM_DATABASE"; + break; + case ID_CLASS: + sprintf(modalias, "pci:v*d*sv*sd*bc%02X*", id1); + key = "ID_PCI_CLASS_FROM_DATABASE"; + break; + case ID_SUBCLASS: + sprintf(modalias, "pci:v*d*sv*sd*bc%02Xsc%02X*", id1, id2); + key = "ID_PCI_SUBCLASS_FROM_DATABASE"; + break; + case ID_PROGIF: + sprintf(modalias, "pci:v*d*sv*sd*bc%02Xsc%02Xi%02X*", id1, id2, id3); + key = "ID_PCI_INTERFACE_FROM_DATABASE"; + break; + } + + if (key) + udev_list_entry_foreach(entry, udev_hwdb_get_properties_list_entry(hwdb, modalias, 0)) + if (strcmp(udev_list_entry_get_name(entry), key) == 0) + return udev_list_entry_get_value(entry); + } +#endif + + id12 = id_pair(id1, id2); + id34 = id_pair(id3, id4); if (a->id_hash) {