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 (worst case scenario is a method, which takes three arguments - method id, instance and an input buffer). We could try and do something like this for methods & data blocks: /sys/firmware/acpi/wmi/<GUID>/ -> type (method, event, data) instance_count (maximum number of instances - method's & data only) Then have the following directory for each possible instance: /sys/firmware/acpi/wmi/<GUID>/<instance>/ Inside, we'd have two files: method_id (methods only) data For data blocks, it's easy -> just read/ write from data (wmi.c could also try to be clever, and set the correct read/ write permissions by checking for appropriate methods). For method calling -> This is more complicated, since we need to pass a method id and the input data (and unlike instance, WMI-ACPI does not define the maximum number of methods). We could do this by writing to a file called method_id first with the method_id we want to call, then read/ write to data (but I'm open to suggestions for a better interface). Events would, I imagine, be some sort of polling, although probably split over two files: One file to tell the polling application of the event, another file (say 'data'), containing the data associated with that event? Unless there's another way we can export the events without polling? -Carlos -- E-Mail: cathectic@xxxxxxxxx Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
