Re: [PATCH 1/4] properly create kobjects in acpi/scan.c

Dmitry Torokhov
2004-08-24T17:03:48Z

On Tuesday 24 August 2004 10:23 am, Hiroshi Miura wrote:
> Hi,
>
> At Tue, 24 Aug 2004 01:34:15 -0500,
> Dmitry Torokhov wrote:
> > 04-acpi-multiple-readers.patch
> > - allow multiple readrs access /proc/acpi/event, every event is
> > delivered to all readers. Also limit number of pending events
> > to 64 (per reader) so if reader is stuck ACPI does not consume
> > all memory.
> >
> > Can be user by various daemons, I could see cpufreqd listening
> > for battery insertion/removal events and debugging is much
> > easier too.
>
> 'acpid' has soket interface for other daemon/utillities.
>
> from man acpid
> In addition to rule files, acpid also accepts connections on a UNIX
> domain socket (/var/run/acpid.socket by default). Any application may
> connect to this socket. Once connected, acpid will send the text of
> all ACPI events to the client. The client has the responsibility of
> filtering for messages about which it cares. acpid will not close the
> client socket except in the case of a SIGHUP or acpid exiting.
>
> I think it is enough.

I do not think that present implementation of acpid has to be a prerequisite
for all setups. Plus, tunneling events through acpid introduces unwanted (IMHO)
dependencies: acpid has to be started first, restarting it can mess up other
processes reading from it's socket, etc, etc...

Given how cheap multiple readers implementation is and the fact that exclusive
only access only causes troubles (think psaux in older kernels) I think it
should go in.

> If allow multiple readers, acpid and other tool need some lock facility to avoid
> unwanted multiple event handling.
>

Well, since acpid manifests that it will pass _all_ events to its readers the
same issue exists right now.

--
Dmitry