On 7/27/06, Daniel Barkalow <barkalow@xxxxxxxxxxxx> wrote:
Maybe it would be best to have a virtual driver that knows about the union of the features, and makes whatever features are provided by the underlying driver available to userspace. That way, all of the drivers are implementing features out of a shared set, so you don't end up with thinkpad/force_discharge and something/discharge_battery. This is the principle behind, for example, the generic cdrom driver, which doesn't actually implement much but rather provides uniformity across devices handled by different drivers. I don't think this is a case where each driver provides very similar functionality, but with critical differences which can't be corrected for; it seems like features are clearly available or not.
It's a bit trickier than it first looks. For example, take the "force discharge" and "inhibit charge" commands. Do they take effect until further notice, or for a given time period? Whichever variant you pick, the ThinkPad hardware can't do it: you can only tell it to force discharging until further notice, and you can only tell it to avoid charging for N minutes. Note that the variants cannot emulate each other, because when the laptop is suspended the embedded controller still ticks but the kernel can't use timers to issue new commands. Another examle: suppose one hardware interface provide average power reading while another interface provides only voltage and average current. The two are not equivalent: if you try to compute power as voltage*current you'll get inaccurate results, because power is the integral over (instantaneous current)*(instantaneous voltage) and the latter fluctuates. So you'd want to somehow prioritize the first interface over the second, at least when it comes to power readings. These details are inconsequential for most applications, but some do care. So an interface that forces a certain view and hides the rest may not be a good idea. Shem - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
