>> Not APM support exactly... simply support for the same interface. Just like >> powermacs have totally different sound systems and still use /dev/dsp. >> /proc/apm and /dev/apm_bios are so simple that it should be easy to convince >> any power management system to provide those API's. > >The info logged to /proc/apm is currently logged to /etc/power/apm. I have >no idea what /dev/apm does aside from providing that log info, and I have >no clue what /dev/apm_bios does, either. There should be no major problems >duplicating the pmu logging code in the kernel, and interfacing that with >some apm glue code, assuming the apm interface is reasonably architecture >independent. I just don't see a good reason to change from pmud to apmd, >if that's what you're suggesting.
At least one reason: the current pmud does continuous polling of the PMU via /dev/pmu. On newer (core99) machines, the PMU itself will send messages to the CPU when any environement info change (battery status, lid closed, ...). We currently don't use this feature and so end up communicating with the PMU more than we would really need. We can "fix" that by either having the PMU driver on core99 continuously send those infos via /dev/pmu without explicit request. It may also be interesting to replace this by a kernel thread. That would allow more flexibility in communicating with userland (things like signaling processes that asked for it to be notified of a sleep request, etc...). One other issue we have with sleep is that we need to prevent the kernel to do a bunch of thigns while going to sleep. scheduling from within the sleep ioctl is dangerous, but will happen occasionally, especially when sleeping & waking up the IDE layer. I beleive it should be possible to hack the scheduler so that only our sleep thread gets scheduled at all (disabling scheduling on the main CPU and freezing other CPUs in sleep loops) during the sleep & wakeup process. Any better ideas ?
