Hi Pavel,
On Fri, 2 Mar 2007 12:40:23 +0100, Pavel Machek wrote:
That's a secondary problem. The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly fail to load,
which would be a move in the right direction. Ideally we would be able
to synchronize the accesses between ACPI and the other drivers, but if
we can't, I'd already be _very happy_ to just prevent conflicting
drivers from being loaded at the same time.
So, can ACPI actually reserve the ports it accesses?
Correct, and on most notebooks, traditional hardware monitoring
drivers do not work anyway. Or I should say, used to not work. The
recent CPUs have embedded sensors which can be read using Rudolf
Marek's k8temp and coretemp drivers, this works on laptops as well.
Chances are good that future laptops will not include a separate
temperature sensor but will read the temperature from the CPU directly,
which will cause conflicts with our drivers.
Now the problem is that we can't blacklist SMBus and hardware
monitoring drivers on all laptops by default. There may be other
devices on the SMBus which the user can legitimately want to access,
such as EEPROMs or RTCs.
What kind of whitelist do you have in mind? We can't realistically
maintain an ever-growing whitelist of hundreds of entries in the
kernel. We could block all laptops by default and maintain a white list
only for them, and a black list for other systems, the would probably
limit the maintenance work, maybe not to an acceptable level though.
Anyway I would definitely prefer the resource conflicts approach, as it
wouldn't need maintenance at all.
Agreed.
Great, looking forward.
--
Jean Delvare
-
