On Mon, Apr 8, 2013 at 8:30 AM, Michael Tokarev <m...@tls.msk.ru> wrote: > 06.04.2013 16:02, Guido Trotter wrote: >> On Sat, Apr 6, 2013 at 11:05 AM, Michael Tokarev <m...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org