Re: [PATCH v4] ACPI: WMI: Add WMI-ACPI mapper driver

[Carlos Corbacho <cathectic@slackadelic.com>]

On Wednesday 31 October 2007 00:18:19 Carlos Corbacho wrote:
> On Tuesday 30 October 2007 22:52:30 Carlos Corbacho wrote:
> > On Tuesday 30 October 2007 18:18:22 Len Brown wrote:
> > > When I consulted Anas about WMI, he recommended that Linux
> > > expose WMI via CIMOM.  I think that this means we'd need
> > > to invent a sysfs interface for this acpi->wmi driver
> > > to expose the hooks to a user-space daemon, which
> > > would then make sense of it in Linux's management framework.
> >
> > The main problem to overcome with a sysfs interface is that a
> > WMI-ACPI call takes multiple values.
>
> So, thinking this over more carefully, whilst sysfs can probably be used to
> export data, I'm not entirely convinced for using it to input arbitrary
> data types, unless there's some way we can get round this?

After sleeping on the matter, I'm now certain that sysfs is the wrong way to 
go for allowing userspace to access WMI-ACPI - we're trying to pass and 
return too much data for sysfs to handle.

So, what we can do is modify the proposed internal kernel calls for userspace 
(since a little sleep is a wonderful thing) to something like:

wmi_evaluate_method(const char* guid, __u32 instance, __u32 method id, void 
*input, __u32 input_size, void *output, __u32 output_size)

(wmi_evaluate_method could be shrunk to just _one_ buffer, since the WMI-ACPI 
spec suggests the mapper should only take & return one buffer).

wmi_query_data(const char* guid, __u32 instance, void *output, __u32 
output_size)

wmi_set_data(const char* guid, __u32 instance, void *input, __u32 input_size)

(Event handling is a little more tricky - we could create a 
new 'wmi_event_handler', and allow userspace or in kernel drivers to register 
this handler with the WMI-ACPI mapper, and avoid polling).

Then, we leave it up to OpenWBEM, etc to write their own backend to handle 
WMI-ACPI (I'm not sure if "provider" is the right terminology to use with 
WMI-ACPI, since we're just converting WMI calls to ACPI). This backend would 
take a WMI-ACPI method call, and convert that to the correct kernel function 
call (the kernel function then handles making the ACPI call and returning the 
results). Interpretation is left to the backend and its associated MOF.

(For the case of WMI not being built in, we define all the functions to return 
an error, or if WMI is enabled but there is no WMI-ACPI mapping device, wmi.c 
would return the errors instead).

Would this be an acceptable solution? (Len - If this is the case, where do we 
expose the wmi_* functions to userspace? linux/acpi.h, or create a new 
include file?)

-Carlos
-- 
E-Mail: cathectic@gmail.com
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D