> > 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.
It indeed has the option: FEATURE_ACPID_DEPRECATED > (Is there ever a reason to need both in one binary?) Let us see. I'm interested in acpid in to ways: real ACPI events (lid closed, power supply changed, ...) and laptop special keys which are still reported via deprecated ACPI interface, not evdev. Until the latter is used to deliver special keys events, one has to enable deprecated /proc/acpi/event. There IS a reason to listen to both, but it is not provided by now. > 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?) I mean one should use runsv (runit way) to spawn this applet. 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...) You are right, since vanilla acpid daemonizes itself, BB's one should mimic its behavior. It should require a trivial change in code. Though I find quite dumby to keep propagating bad habits... IMO no applications should daemonize itself. Why on Earth they are supposed to be so clever? That is why I asked whether to rename BB acpid to, say, uacpid, since not only starting mode is different, but so is the way on configuration. -- Vladimir
_______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
