Vladimir Dronnikov wrote: > Cool. > What do you think, Jason: > i) Is /proc/acpi/event so deprecated like they claim it? What should > we call "ACPI events" then: only the "true" ACPI events (change in > power supply, power and sleep button, etc.) or generic hotkeys (which > are _still_ delivered to userspace via ACPI subsystem) too? > In the former case we can safely drift to just polling > /dev/input/event*; the latter case would require additional > /proc/acpi/event polling. > At least in the embedded world, we have more choice about what kernel we're running. I think it's more important to have the feature working with a kernel, and we can decide to "fix" it later to use the new interface. But likely supporting the old interface is more important while I don't think that 2.6.21 has the newer interface. Make it an option later which one you want.
I've got a power button and a reset button... Put that in and let's see what other people need. > ii) Should we use vanilla acpid configury (which I find ugly) or try > to use run-parts like I'm proposing? Any objections? > I've avoided the acpid package for now so I don't know how it does this. Your run-parts seems good and modular. I don't know if you'd have multiple scripts, or just one with parameters being passed (like udhcpd). I can live either way as I'll be building from scratch. If you're writing it, work with what you're most comfortable with :) > TIA, > -- > Vladimir > > Do svidanya, Jason. _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
