On Thu, 2010-04-01 at 07:18 -0600, Joey Lee wrote: > 於 二，2010-03-30 於 17:31 +0100，Thomas Renninger 提到： > > On Tuesday 30 March 2010 18:12:40 Joey Lee wrote: > > > 於 二，2010-03-30 於 10:23 +0100，Thomas Renninger 提到： > > > > What userspace tools are candidates to implement this if this > > > > makes sense? > > > > > > HAL + pm-util or DeviceKit-power might the candidates. But, if there > > > have no those component in userland, what will acpi thermal module do? > > > Direct shutdown? > > > And, how can kernel space know userland can do this job well? Might wait > > > 10 seconds if system doesn't S4 or shutdown? > > Yep, my idea is to e.g. provide: > > /sys/class/thermal/S4_capable > > By default you get: > > cat /sys/class/thermal/S4_capable > > 0 > > and the thermal driver will call the same shutdown method > > if the hot thermal tp is reached as if the critical is reached. > > > > If pm-utils does: > > echo 1 >/sys/class/thermal/S4_capable > > it has to make sure it picks up acpi thermal hot event and initiates > > S4. If S4 fails for whatever reasons (no swap, > > stroking some kernel drivers fails, unmounting file systems fails, ...), > > it has to make sure to force a system shutdown (just call /sbin/poweroff > > the same way the kernel does currently with a critical thermal event?). > > Emergency shutdown is then out of kernels hand (as it is currently for HOT > > anyway which is dangerous). What would be the event source? pm-utils is not a process, it can't pick stuff up, I EXPECT, unless the kernel would fork a certain binary. > > Hmm, this is acpi specific, possibly it should be a new dir here: > > /sys/firmware/acpi/thermal/S4_capable > > or something else? > > > > Your idea looks good to me, but, the DeviceKit-power will rename to > upower, Yes, it did already a while ago. > We are discussing about how to handle the situtation if BIOS ACPI didn't > return the _CRT value, and even have _HOT value, if S4 fail, what can we > do on kernel space and userland. > > _CRT value is the shutdown critical temperature > _HOT value is the critical temperature for sleep (entry to S4) > > Per ACPI spec: > The platform vendor should define _HOT to be far enough below _CRT so as > to allow OSPM enough time to transition the system into the S4 sleeping > state. > > Currently, there have a bit platform provider (OEM/ODM) only return the > _HOT, but didn't have _CRT value. But, if _HOT S4 fail, the system > components might dangerous if there have no any hardware protected > Mechanism. > > Thomas's idea is add a sysfs interface /sys/class/thermal/S4_capable for > userland to tell kernel userland component (pm-util or upower?) already > take the _HOT event and try to do S4. > > How do you think about this idea? I'm not so sure, this sounds a bit like an ad-hoc interface for a pretty specific problem. I would expect, it needs more integration than a global sysfs flag that keeps its state even when no userland process is taking care anymore. The details should probably be discussed on a mailing list like devkit-devel@xxxxxxxxxxxxxxxxxxxxx and the people working on the userspace integration side should comment on it. Cheers, Kay -- 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
