On Monday 20 October 2008 02:52:01 Vladimir Dronnikov wrote: > Sorry, I had to be brief... > > It needs more documentation. (Spawn specific application... what > > > application(s)? Is it in /etc/acpi? What's the format of that?) > > acpid listens to ACPI events coming either in textual form from > /proc/acpi/event (though it is marked deprecated it is still widely used > and is standard) or in binary form from specified evdevs (I use > /dev/input/event* while testing).
Sounds like it needs an either/or config option then, "use old /proc interface (deprecated)". If you don't select it, include the binary parsing code from /dev/input. (Is there ever a reason to need both in one binary?) > It parses the event to retrieve ACTION and a possible PARAMETER. > It then spawns /etc/acpi/<ACTION>[/<PARAMETER>] either via run-parts (if > the resulting path is a directory) or via sh -c unless. If the resulting > path does not exist it logs it via perror and continues listening. Ok. > It is intended to be run as service so it does not daemonize. Er, service in what way? (Could you elaborate on that sentence? How does it differ from httpd and other programs that end in "d" for daemon?) Normally they daemonize by default and have a command line argument to _not_ do that. I suppose we could put a "daemonize" wrapper in busybox (er, isn't that what "detach" traditionally does?), but then there's a UI issue with existing users and I don't know if it would actually save any space. (Nice increase in flexibility, I suppose...) > --Vladimir Rob _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
