Hardware certification device information

[Stefan Bader]

Marc Tardif wrote:
> Hi again folks,
> 
> I'm already done with most of the implementation which should be in
> production this week barring any unforeseen complications. The result
> of my exploration has determined that the following information will
> prove to be sufficient for uniquely identifying and representing the
> devices in a system:
> 
>     path: sysfs path used to determine the hierarchy of devices
>     bus: subsystem name corresponding to the subsystem symlink
>     category: initial attempt to categorize devices
>     driver: the drivers used by the device
>     type: the content of the type file under some devices
>     vendor_id: for vendors of pci, usb or pnp devices
>     product_id: for products pci, usb or pnp devices
>     subvendor_id: subsystem vendor id for pci devices
>     subproduct_id: subsystem product id for pci devices
>     vendor: for devices with vendors identified by string
>     product: for devices with products identified by string
> 
> For completeness purposes, I have attached the result from gathering
> the above information using Checkbox. Note that if the vendor and
> product information are None, this means they will be determined on
> the server side by looking at the latest id tables parsed from
> reference sites.

It is a bit a mix between physical devices and subsystems. I am not really 
decided how often the subsystem information will be required, but heck it is 
not much more data and better to have it than not.
Maybe I throw myself behind the train with this, but does the data include some 
dmi information (system vendor, bios version, model, memory)?

> There is still one problem I haven't been able to solve: the type
> file which is sometimes available for some devices under the sysfs,
> is this specific to a device instance or a device model? In other
> words, can the content of this file change between systems of the
> same model or even between different versions of the kernel?

To me it seems like a non-standardized field and might be both. For that maybe 
we should just ignore it. Does someone else know a case where it would be 
important?

> If you have any other comments, please let me know.

Just the one, that I tried to access the site and i told me I am not worthy to 
do so. Strange I thought I once was. I remember asking Ronald and he actually 
found I am defined...

> * Pete Graner <pgraner at canonical.com> [2009-08-30 16:38 +0800]:
>> Pls get on this ASAP, Marc needs this info so that your jobs will be  
>> easier, I'd like everyone's comments by the end of this upcoming week.
>>
>> Marc Tardif wrote:
>>> The hardware certification website is being refactored so that devices
>>> can be searched effectively. Ultimately, you should be able to identify
>>> the systems which contain the devices you might need to reproduce bugs
>>> or confirm that a fix actually works.
>>>
>>> The hardware certification database used to rely on HAL information, but
>>> this is being refactored to rely on udev instead. What I need from you
>>> is the list of properties from the udev database and attributes from the
>>> sysfs which would need to be structured in the database so that they can
>>> later be searched.
>>>
>>> For your convenience, I have attached the following files generated on
>>> my system to identify some of the relevant properties and attributes:
>>>
>>> properties.txt: These are the properties, also referred to as the
>>>   environment (E) in udev. This is basically the filtered output of
>>>   `udevadm info --export-deb`.
>>>
>>> attributes.txt: These are the attribute detected by udev from the
>>>   sysfs for each device. This is basically the filtered output of
>>>   `udevadm info --attribute-walk --path=...` for each device.
>>>
>>> devices.txt: This is the combined output of the udev database and the
>>>   corresponding sysfs attributes, so that the information can be easily
>>>   correlated. I'm hoping this might provide useful examples from my
>>>   system in the event some properties or attributes aren't clear.
> 


-- 

When all other means of communication fail, try words!