Re: simple userspace pm interface

[John Fremlin]

"Grover, Andrew" <[e-mail]> writes:

[...]

> - It's probably easier to put the "event" file in proc, instead of
> dev. This is what the acpi interface does, and eliminates the mknod
> step.

Is this kernel policy? I mean, you could apply the same argument to
all device nodes ;-)

> - perhaps rename boxevent() to event() or sys_event()?

Event is a bit generic, and sys_event is vague. I agree that boxevent
is not a pretty name, but it gives a vague suggestion of
hardwareness. hwevent looks ugly - what do people think?

> - Consider putting the subsystem/class identifier first
> - Consider hiding the source of the event. For example, we shouldn't care
> that the power button press was generated by APM or MIPS64, because we're
> going to take the same action, regardless.

The suggested action is given as the first word. The second word is
the subsystem, in order to avoid namespace collisions: you could have
two different PM systems active on your machine at different times,
(e.g. ACPI and APM) and this lets you distinguish between them. You
could think of it as the first word being the suggested action and the
rest being a description.

> I'd encourage you to take a look at the ACPI code that does
> something similar (in 2.4.4ac4 or greater, or grab the code from the
> website at
> http://developer.intel.com/technology/iapc/acpi/downloads.htm .)
> Specifically, grep -r for bm_osl_generate_event(). Modifying that
> code to be more general-purpose could possibly meet ACPI's needs as
> well as everyone else's.

ACPI_STATUS bm_osl_generate_event (
       BM_HANDLE               device_handle,
       char                    *device_type,
       char                    *device_instance,
       u32                     event_type,
       u32                     event_data)
{

The function could quickly be converted to boxevent without thinking

sprintf(buffer,"device %s instance %s says %x: %x",
        device_type,device_instance,event_type,event_data);
boxevent(BOXEVENT_NOTIFY,"ACPI",buffer);

this would provide all of the current functionality available from
ACPI (ATM the code does sprintf(str, "%s %s %08x %08x\n") to the
userspace reader) but boxevent also handles poll, short reads, and
event floods, etc.

Some one who knows about ACPI could change the BOXEVENT_NOTIFY to a
better suggestion based on event_type or something.

[...]

-- 

	http://ape.n3.net