From: Carlos Corbacho <cathectic@slackadelic.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: linux-acpi@vger.kernel.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v4] ACPI: WMI: Add WMI-ACPI mapper driver
Date: Tue, 30 Oct 2007 14:28:10 +0000 [thread overview]
Message-ID: <200710301428.11471.cathectic@slackadelic.com> (raw)
In-Reply-To: <20071030134701.GA11877@srcf.ucam.org>
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@gmail.com
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
next prev parent reply other threads:[~2007-10-30 14:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-30 3:36 [PATCH v4] ACPI: WMI: Add WMI-ACPI mapper driver Carlos Corbacho
2007-10-30 13:47 ` Matthew Garrett
2007-10-30 14:28 ` Carlos Corbacho [this message]
2007-10-31 10:56 ` Carlos Corbacho
2007-10-30 18:18 ` Len Brown
2007-10-30 22:52 ` Carlos Corbacho
2007-10-31 0:18 ` Carlos Corbacho
2007-10-31 12:21 ` Carlos Corbacho
2007-10-31 16:24 ` Carlos Corbacho
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200710301428.11471.cathectic@slackadelic.com \
--to=cathectic@slackadelic.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox