On Tue, 18 Mar 2008 11:45:52 +0800, Zhang, Rui wrote: > On Mon, 2008-03-17 at 21:48 +0800, Jean Delvare wrote: > > Rui, Len, how did you originally envision the coexistence (or not) of > > different types of thermal zones? > > driver/thermal/thermal.c won't change any behavior of the current > system. It just creates a generic sys I/F, that's why we call it the > Generic Thermal Sysfs driver. :) > > We want to introduce a generic solution for thermal management, which > usually contains a user application for policy control, a generic > thermal sysfs driver which provides a set of platform-independent > interfaces, native sensor drivers and device drivers for thermal > monitoring and device throttling. > Note that the target is the handheld devices which is not covered by > hwmon. > The idea comes from Len's ols paper, please refer to > http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/doc/OLS2007-cool-web/ > > I don't think the generic thermal sysfs driver need to handle the > coexistence of different types of thermal zones, because: > If there are any, they always exist without the generic thermal driver. > If they break something, it's broken before the generic thermal driver > is implemented, and the generic thermal driver give it a chance to > handle this in user space. > Please correct me if I misunderstand your question. :) Maybe I have not been clear, but my question was not about the generic thermal driver itself. I understand that it's only adding an interface to other drivers and not creating anything new. My question was about thermal zones in general, i.e.: Do we expect systems to have more than one thermal zone type at a given time, or not? Len seems to think we do. -- Jean Delvare -- 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
