On 7/27/06, Daniel Barkalow <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
