acpid

[Vladimir Dronnikov]

>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20081021/05ba8a92/attachment-0002.htm