Hi. On Thu, 2005-03-10 at 15:31, David Zeuthen wrote: > On Thu, 2005-03-10 at 10:28 +1100, Nigel Cunningham wrote: > > That sounds good from the kernel->userspace side, but hideous from the > > other perspective! But perhaps I'm just being ignorant :> Say a > > userspace daemon learns that we've just lost AC and have 3 minutes of > > UPS power left. I guess it would notify HAL, > > Actually HAL now knows about usbhid UPS'es now and export them like > other batteries :-) > > > but wouldn't we then want > > HAL to notify kernel space? Or would you imagine HAL directly saying to > > drivers, "Video driver, turn the monitor off if you haven't already."? > > > > I could imagine some policy piece doing this, yes. It wouldn't be HAL, > but something using HAL to enforce policy - I suppose we could teach HAL > (or just a script, or even the kernel) about exporting a method > minimizePowerUsage() that would do the right thing and said policy > enforcing pieces would use that? (possibly respecting the users settings > e.g. the "[x] Allow system to suspend this device if inactive") > > What I think is interesting here is a) making sure that the > kernel<->user space interface is there for making sure that user space > plays nicely with the kernel, e.g. HAL should stop polling a storage > device if the kernel says it's going to sleep (hence notification); and > b) providing a way for user space to configure policy (but let the > kernel enforce it), such as "never put this device to sleep" or "put to > sleep after N seconds of inactivity", hence writing to a sysfs > attribute. > > Does that clarify? Yes, thanks. Regards, Nigel -- Nigel Cunningham Software Engineer, Canberra, Australia http://www.cyclades.com Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574 Maintainer of Suspend2 Kernel Patches http://suspend2.net
