Opened 11 years ago
#550 new enhancement
Driver wildcard matching
| Reported by: | Jiri Svoboda | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | helenos/unspecified | Version: | mainline |
| Keywords: | Cc: | ||
| Blocker for: | Depends on: | ||
| See also: |
Description
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 2N-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.
