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.
Without being intimately familiar with Launchpad internal requirements for devices, this is what I might propose as a schema to express each device:
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.
Without being intimately familiar with Launchpad internal requirements for devices, this is what I might propose as a schema to express each device:
<define name="device">
<attribute name="value">
<text/ >
</ attribute>
<element name="driver">
<attribute name="value">
< text/>
</attribute>
</ element>
<element name="vendor_id">
<attribute name="value">
< ref name="integer"/>
</attribute>
</ element>
<element name="product_id">
<attribute name="value">
< ref name="integer"/>
</attribute>
</ element>
<element name="subvendor _id">
<attribute name="value">
< ref name="integer"/>
</attribute>
</ element>
<element name="subproduc t_id">
<attribute name="value">
< ref name="integer"/>
</attribute>
</ element>
<element name="vendor">
<attribute name="value">
< text/>
</attribute>
</ element>
<element name="product">
<attribute name="value">
< text/>
</attribute>
</ element>
<interleave>
<element name="bus">
</element>
<optional>
</optional>
<optional>
</optional>
<optional>
</optional>
<optional>
</optional>
<optional>
</optional>
</interleave>
</define>