On 23.08.2009 01:14, Marc Tardif wrote: > Instead of dumping raw text files which will change as new udev rules > are introduced, I would propose that Launchpad exposes an API defining > what it defines as a device. The current implementation is obviously > coupled with what HAL defines as a device. Only a fraction of this > information is actually used by Launchpad, so there seems to be a divide > between both definitions. Right, Launchpad uses only a relatively small part of that data. But I am not sure if the client should do too much processing of the data. If we notice an error, it is hard to fix, and we might need to throw away lots of submissions. Errors during server processing are much easier to track and to fix. To give an example where things become a bit difficult: The kernel controls most storage devices via the SCSI layer, meaning that we have for nearly each IDE disk and nearly each USB stick a "virtual" SCSI device, controlled by a "virtual" SCSI controller. If you have a look into the LP file lib/canonical/launchpad/scripte/hwdb-submissions.py, you'll see a number of other "special cases". The script may need sometimes some additional data from parent devices. Hence I think it is better to store all the data we get from udev (and at least some additional data from the "attribute files" in sysfs. > > Without being intimately familiar with Launchpad internal requirements > for devices, this is what I might propose as a schema to express each > device: > > > > > > > > > > > > > > > > > > > > > > > > > > > bus, vendor_id and product_id are all required attributes -- that's what the LP database needs to identify a device. > > > > > > > > > > > > > > > > > > > > > > > > > > > > >