On Sun, Jan 22, 2006 at 11:24:15PM +0100, Marco d'Itri wrote: > On Jan 12, Mattia Dongili <malattia@linux.it> wrote: > > > No. That's the kernel only supporting a single reader for /proc/acpi/event. > > I'm cooking a patch to support multiple readers (based on an old and never > > applied patch) but I doubt it will be accepted mainline. > > /proc/acpi/event contention has _always_ been a problem and the only > > solution is to support multiple readers, not to require acpid's socket, > > that's just ridiculous :) > It's not up to you to decide that a kernel interface is wrong, at least > without the ACPI maintainer agreeing. of course, but I'm still convinced that not supporting multiple readers for /proc/acpi/event is a bad idea. And the fact that nowadays also X wants to read it makes it even worse. > Arguing that this will be fixed by a kernel patch which does not exist > and will probably be rejected (and even if it were accepted would be in > Debian kernels in a 2-4 months timeframe) is not acceptable, this needs It's already been rejected once (quite a long time ago) and I don't expect it to be applied in the future as it's an ugly hack IMO (and I still haven't found any time to rebase it against current kernels). > to be fixed in X (I suggest by retrying to open the socket if it worked > the first time). this is exactely what the patch I submitted here does. But it does only once, so if the socket is not there on the first retry it'll steal /proc/acpi/event. > "breaks unrelated software" is one of the criteria for critical bugs, > and even if 6.9 needs to move to testing ASAP it's not a reason to take > this bug lightly. > > > With my patch if acpid dies xorg reopens /proc/acpi/event. > > > > So, I'd say this is either an acpid bug (start earlier?) or better yet a > > kernel bug. > Wrong, because acpid is normally restarted during the X server life > cycle (on upgrades and by logrotate) so X needs to cope with it. and on some suspend/resume paths to workaround spurious button events. But who can tell which is the grand-piece-of-sw that has the exclusive right to open /proc/acpi/event? BTW: I also submitted a different (more conservative?) patch that simply drops ACPI support if the socket disappears. So whose bug is this? One could also argue that acpid should handle restart in a smarter way as closing the socket breaks _all_ "unrelated software" that listens to it. And the most obvious way to cope with it is to retry immediately and eventually take /proc/acpi/event if available. -- mattia :wq!
Attachment:
signature.asc
Description: Digital signature