All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Len Brown <lenb@kernel.org>
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>,
	Alexey Starikovskiy <astarikovskiy@suse.de>,
	linux-acpi@vger.kernel.org,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Subject: Re: [RFC] EC registers - Adding sysfs interface?
Date: Fri, 07 Dec 2007 09:53:04 +0100	[thread overview]
Message-ID: <1197017584.28990.98.camel@queen.suse.de> (raw)
In-Reply-To: <200712062152.56939.lenb@kernel.org>

On Thu, 2007-12-06 at 21:52 -0500, Len Brown wrote:
> On Wednesday 28 November 2007 11:28, Thomas Renninger wrote:
> > On Tue, 2007-11-13 at 19:03 +0000, Carlos Corbacho wrote:
> > > Alexey,
> > > 
> > > > How about character /dev/ec0?
> > > 
> > > Yes, that would be fine.
> > > 
> > > On Tuesday 13 November 2007 18:54:51 Alexey Starikovskiy wrote:
> > > > What is the benefit of having acer_acpi in userspace, rather than one more
> > > > *-laptop in /devices/misc?
> > > 
> > > A debate of "would it be easier for me to maintain an in kernel driver (if/ 
> > > when I can get it upstream) or a userspace application". At the moment, the 
> > > idea of a full blown userspace application is just something I'm toying with 
> > > in my head whilst working on WMI userspace.
> > 
> > I very much like the idea of a general EC debug/devel interface to
> > userspace.
> > It should be a separate CONFIG, marked "DEBUG", "EXPERIMENTAL" or
> > whatever and be per default off.
> > It is stupid that everybody who wants to debug a bit on EC registers
> > needs to duplicate the IBM EC implementation, this should IMO be moved
> > where it belongs to:
> > drivers/acpi/ec.c
> > 
> > The question is whether Len will accept/like it, Len?
> 
> 
> It is crazy to poke ioports from user-space when ec.c thinks it owns them.
> So if you're going to do so, it would certainly be an improvement
> to go through the driver rather than around it.
> 
> What other users of this interface would there be other than
> a user-space version of acer_acpi?
> If a user-space driver
> were using the I/F, then we couldn't make it a DEBUG-only feature,
> it would have to be enabled all the time.

I see the "danger" of applications misusing this as an interface and
implementing workarounds for unsupported ACPI parts and (this is the
real problem) stop working on the real problems or a proper
implementation.

Especially because this option should be compiled in e.g. OpenSUSE
versions, for better remote debugging (comparing EC register values with
DSDT Embedded Controller variable implementations on a related problem
could help a lot, without the need of digging in the dark for weeks...).

>From your comments above, I read out that you tend to accept such an
interface as suggested by Alexey?
Making it read-only by default, would mainly help debugging purposes and
should avoid any workaround implementations.

   Thomas


  reply	other threads:[~2007-12-07  8:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-13 17:24 [RFC] EC registers - Adding sysfs interface? Carlos Corbacho
2007-11-13 18:40 ` Alexey Starikovskiy
2007-11-13 18:46   ` Alexey Starikovskiy
2007-11-13 18:49   ` Carlos Corbacho
2007-11-13 18:54     ` Alexey Starikovskiy
2007-11-13 19:03       ` Carlos Corbacho
2007-11-28 16:28         ` Thomas Renninger
2007-11-28 18:25           ` Alexey Starikovskiy
2007-11-28 23:12             ` Henrique de Moraes Holschuh
2007-12-07  2:52           ` Len Brown
2007-12-07  8:53             ` Thomas Renninger [this message]
2007-12-10 20:36               ` Henrique de Moraes Holschuh
2007-11-14  2:40 ` Henrique de Moraes Holschuh

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=1197017584.28990.98.camel@queen.suse.de \
    --to=trenn@suse.de \
    --cc=astarikovskiy@suse.de \
    --cc=carlos@strangeworlds.co.uk \
    --cc=hmh@hmh.eng.br \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.