id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	field_blocks	field_dependson	field_seealso
550	Driver wildcard matching	Jiri Svoboda		"Currently drivers are matched to device nodes based on exact string match (each driver declares a set of match IDs and each device node has a set of match IDs). Typically a bus driver encodes a set of properties to the match-ID string (e.g. vendor ID, device ID, class ID, subclass ID, etc.) Different drivers may match different subsets of these properties, e.g. a subclass driver will match the class ID, a driver for a specific device will match vendor ID and device ID, etc.

This forces the bus driver to export one match-ID string for every possible property subset a device driver might want to match against. I.e. if we consider N properties for matching, the bus driver needs to export up to 2^N^-1 match-ID strings. This is not very elegant.

One option would be to introduce some kind of wildcard-search, for example if the bus driver defines a device's match ID string to be

{{{
vendor-id=a&device-id=b&class=c&subclass=d
}}}

a driver's match ID could be a pattern like:

{{{
vendor-id=a&device-id=b&class=*&subclass=*
}}}

(or something completely different)

There are different possibilities, depending whether the match ID would be considered a flat string or to have some structure understood by the framework, etc.
"	enhancement	new	minor		helenos/unspecified	mainline