On Tuesday 30 Otober 2007 13:47:01 Matthew Garrett wrote: > I suspect that for a lot of cases, exporting this to userspace would be > helpful - it's often easier for us to do this mapping in hal and just > push out an updated fdi file than it would be to push out an updated > kernel driver. But what would be mapped via HAL? WMI is such a completely undefined "standard", that not only do you have to map the GUIDs, but you'd also have to map the program logic as well (marshalling arguments, restricting function parameters, call order, etc) and this strikes me as being beyond the scope of an fdi file. For some methods, which are quite simple, this _might_ be possible. For others I've seen, this will end up a complete mess. If you're going to do all that, you may as well write a driver in kernel space and leave that to export the functionality in a way userspace can already handle. > And for similar reasons, I think it would be helpful to provide > userspace with the ability to trigger WMI calls. It's going to be easier > for people to add GUIDs to a userspace file than to extend a kernel > driver, even if there are some cases that are better handled by having a > full in-kernel driver. There are also other technical problems with this, beyond my own personal disagreement - since WMI relies so heavily on ACPI (well, the driver here is really just a simple wrapper), then you would have to start exporting bits of ACPI to userspace to access WMI. As mentioned in the original patches - the mapper knows nothing about "types", this knowledge is known only by the caller - WMI just deals in acpi_buffer. My understanding is that ACPI would have to export the required functions and data structures so that userspace could provide then translate from acpi_buffer to the known type (unless there is another way round this to import and export the data to/ from userspace?) -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
