public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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

  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