Bug#704815: Would it be possible to reenable CONFIG_ACPID
On Mon, Apr 8, 2013 at 8:30 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
> 06.04.2013 16:02, Guido Trotter wrote:
>> On Sat, Apr 6, 2013 at 11:05 AM, Michael Tokarev <mjt@tls.msk.ru> wrote:
>>> 06.04.2013 12:56, Guido Trotter wrote:
>>>> Package: busybox-static
>>>>
>>>> I know that acpid was disabled on purpose, but would it be possible to
>>>> reenable it? It is useful on VMs running with busybox only, for example.
>>>
>>> For many years, i've the following "replacement" for acpid:
> []
>>> while read x < /proc/acpi/event; do
> []
>> CONFIG_ACPI_PROC_EVENT is deprecated and unset in most modern kernels
>
> I know it's been deprecated, but I always used local builds of kernel
> (together with my initramfs and a few other infrastructure), so I
> didn't know it's been turned off. That's a pity.
>
>> (I know, I can always build my own kernel, but then again, I could
>> also build busybox, so that defeats the purpose). acpid in busybox can
>> read /dev/input/event* and at least under Xen does the right thing
>> (shuts down the system, with the proper config).
>
> Do you aware that any keyboard/mouse/etc event will be read by acpid
> using this /dev/input/event* "interface"? That was my main complain
> when this interface has been introduced - there's no way to filter
> out things to stop kernel to wake all readers for every and all input
> event even if 99.99% the readers aren't interested in it. At least
> acpid can be a bit smarter and only open those devices which actually
> provide buttons we're interested in, like pwrbtn/lidbtn, instead of
> reading every mouse and force-feedback device out there. Oh well.
>
Is there a way to find out which event provides what?
Right now acpid in busybox can only open all of them, or a single
socket which expects the old format (and segfaults on the new one,
sic). So perhaps there can be a few upstream bugs to ask to:
1) not segfault when the wrong protocol is used (segfaulting is never nice)
2) ability to filter which event* to open
> Fortunately it might be not as bad for a VM where you don't work at
> the console.
>
> But this is just, well, complaining, I understand that the whole
> (linux) world already works like that.
Indeed, but I'm sure busybox acpi can be improved as well, by
upstream, if we ask nicely. :)
(Or by us, having time, it seems easy c code).
>>> Is it not sufficient for you?
>>>
>>> If you talk about VMs, I found it is much easier to use Ctrl+Alt+Del
>>> from inittab to signal shutdown, and don't bother with acpi at all.
>>> For this to work, just change cad action in /etc/inittab to do
>>> power down instead of reboot.
>>
>> Under kvm I can always go for the "ctrl+alt+del" option you suggest,
>> but that still requires special knowledge that the machine does the
>> right thing, while acpi is supposed to be more standard. Anyway I am
>> not sure I could easily do that under Xen too.
>
> I see. This, together with ACPI_PROC_EVENT, are both good points.
>
>>> As for enabling this applet for wheezy, it definitely is not possible
>>> at this time because of the freeze.
>>
>> Understood, I only mentioned it because it was enabled in squeeze
>> before, but then again probably busybox is too important to allow
>> exceptions. Well, maybe it can still be discussed and updated in
>> wheezy+1 and backports, perhaps?
>
> Backports - sure. For wheezy, I'll have to explain to the release
> team why fixing this bugreport is important for wheezy, and I'm
> afraid I can't do that even to myself ;)
>
No problem at all, backports is perfect for me.
> Your usage is very specific. There's absolutely no reason why it
> should be forbidden, obviously, and I will, most likely, turn this
> options back on for jessie - for both regular and static builds -
> but this wont be for wheezy. I'm sorry to say that.
>
> Thank you for the feedback and the bugreport! Seriously, it is
> always nice to know which applets people use for real and which
> are dummies.
>
Thanks a lot for your packaging work and your responsiveness!
Guido
Reply to: