2010/12/29 Josà FÃlix OntaÃÃn <felixonta@xxxxxxxxx>:
> El dÃa 29 de diciembre de 2010 01:18, Scott James Remnant
> <scott@xxxxxxxxxxxx> escribiÃ:
>> 2010/12/28 Lennart Poettering <lennart@xxxxxxxxxxxxxx>:
>>> On Tue, 28.12.10 14:14, Josà FÃlix OntaÃÃn (felixonta@xxxxxxxxx) wrote:
>>>>
>>>> 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?
> First thing coming to my mind: there's not enough pci/usb devices
> present on the system for increasing the computational cost
> significantly. Querying the vendor/model names will be performed only
> one time, at udev running, and then only one time on "add" action for
> this subsystems. Am i wrong?
As Greg says, it really can be a lot of devices, and the linear search
in a huge text file isn't exactly what we want to do. We might need a
real indexed database. Ideally one that does not only contain human
readable identifiers but also whatever meta-data which is useful to
users.
> Anyway, taking care about the efficiency, the Scott solutions sounds
> good to me but implies development on udev directly. I'm writing some
> apps using udev so, in the meantime, will be really nice if some more
> questions could be answered:
It's difficult. We run in untrusted user-context, and can not update
the udev database. It would be a major change in the architecture,
which I'm not sure we should get into that. For many of the devices
on-demand will not be sufficient, as we need the symlinks, tags and
other things.
> Is it acceptable to add the mentioned udev rule for a system
> application using udev? I mean, i.e. udisk add some rules for
> importing some props. And for a desktop app? Is it acceptable too?
Sure, you can do that. Just check that it isn't already run before your rules.
> 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.
As Greg already pointed out, you should probably look up the stuff you
need, yourself in the database files.
Udev must not become the new HAL. We need to be very very careful here. :)
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
