linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: PCI/USB Vendor and model from database
Date: Wed, 29 Dec 2010 16:16:34 +0000	[thread overview]
Message-ID: <20101229161634.GA17165@kroah.com> (raw)
In-Reply-To: <AANLkTi=1GzSurOXcFwBJUXfXBch24QB3cRh+0qo1a1Fp@mail.gmail.com>

On Wed, Dec 29, 2010 at 05:08:56PM +0100, José Félix Ontañón wrote:
> El día 29 de diciembre de 2010 01:18, Scott James Remnant
> <scott@netsplit.com> escribió:
> > 2010/12/28 Lennart Poettering <lennart@poettering.net>:
> >> On Tue, 28.12.10 14:14, José Félix Ontañón (felixonta@gmail.com) wrote:
> >>
> >>> Hi, everybody!
> >>>
> >>> Maybe this is kinda silly question but, I wonder why isn't
> >>> "ID_VENDOR_FROM_DATABASE / ID_MODEL_FROM_DATABASE"-like properties
> >>> imported by default using the pretty /lib/udev/usb-db and
> >>> /lib/udev/pci-db commands for every founded pci/usb device?
> >>>
> >>> I mean, by adding this simple rules:
> >>>
> >>> SUBSYSTEMS="usb", IMPORT{program}="usb-db %p"
> >>> SUBSYSTEMS="pci", IMPORT{program}="pci-db %p"
> >>>
> >>> I think this properties are very useful for apps that discover
> >>> hardware through udev, so they will not have to reinvent the wheel by
> >>> finding vendor/product names by themselves. Don't you think?
> >>
> >> The database lookup is a linear search. As long as we invoke it only for
> >> a small subset of devices that doesn't really matter much. But if we
> >> start to look it up for every device we should probably spend the time
> >> to improve the db lookup first.
> >>
> >> It's simply a question of efficiency.
> >>
> > One thing that might be interesting is if we could do the lookup at
> > the point of query, then store the answer back in the db for others to
> > use later.
> >
> > That way we're efficient if nobody cares, and lose that efficiency
> > when they do (but only for the devices they query), and subsequently
> > efficient because the answer is cached.
> >
> > This veers a bit dangerously towards having apps that link with
> > libudev process rules though?
> >
> > Scott
> >
> 
> First thing coming to my mind: there's not enough pci/usb devices
> present on the system for increasing the computational cost
> significantly.

How can you say that?  I see systems with thousands of PCI devices on it
as being very common in some areas.

> I think it's quite comfortable, for me as desktop app coder, to
> delegate on udev the vendor/model name querying, more if we think udev
> provides the cool pci-db and usb-db commands.

Again, what's wrong with using libpci directly for this?  That's what it
is there for.

thanks,

greg k-h

  parent reply	other threads:[~2010-12-29 16:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-28 13:14 PCI/USB Vendor and model from database José Félix Ontañón
2010-12-28 18:45 ` Greg KH
2010-12-28 23:58 ` Lennart Poettering
2010-12-29  0:18 ` Scott James Remnant
2010-12-29 16:08 ` José Félix Ontañón
2010-12-29 16:16 ` Greg KH [this message]
2010-12-29 16:34 ` Kay Sievers
2010-12-29 23:09 ` José Félix Ontañón
2010-12-30  0:08 ` José Félix Ontañón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101229161634.GA17165@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).