public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Linux-pm mailing list <linux-pm@lists.osdl.org>
Subject: Re: [RFC] Disabling Devices
Date: Wed, 11 May 2005 07:04:40 -0700	[thread overview]
Message-ID: <200505110704.40587.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0505091350020.5866-100000@iolanthe.rowland.org>

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

On Monday 09 May 2005 11:06 am, Alan Stern wrote:
> There's an issue here that needs to be discussed explicitly.  How finely
> should the kernel allow userspace to control runtime power management?
> 
> ...
>     (B) Or should the kernel export a relatively small set of power 
> 	domains and a small set of primitives for each domain?  Like:
> 	suspend, turn off remote wakeup, go to full power, suspend
> 	after N seconds of inactivity?
> 
> ...
> 
> In general (A) most resembles what sysfs does right now.  I suspect that 
> (B) will be a better solution in the end.

Yes.


> Regarding Dave's comments about hdparm and xset dpms -- what matters most 
> about these interfaces is not that they are application-specific but that 
> they are ad-hoc. 

How does "application-specific" differ from "ad-hoc" though?
In practical terms; one is more pejorative than the other, but
how exactly does one measure a difference?

For example, the kernel doesn't know about X11 protocol at all,
or those particular IDE protocol requests.  And most folk would
probably say that it shouldn't need to ...


> I don't see why we can't strive to present a much more  
> uniform interface, even if it does describe widely varying subsystems.  I 
> also don't see anything wrong with implementing this interface by means of 
> sysfs instead of using driver-specific ioctls.

For new things, or things being generalized into kernel support,
I've no fundamental issue with using sysfs.  But for things that
are widely deployed today, I don't see much point in changing
interfaces.

- Dave

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2005-05-11 14:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44L0.0505091124370.5325-100000@iolanthe.rowland.org>
2005-05-09 16:51 ` [RFC] Disabling Devices David Brownell
2005-05-09 18:06   ` Alan Stern
2005-05-11 14:04     ` David Brownell [this message]
2005-05-11 19:10       ` Alan Stern
2005-05-13  7:30         ` David Brownell
2005-05-13 15:40           ` Alan Stern
2005-05-09  2:15 Adam Belay
2005-05-09 10:46 ` Pavel Machek
2005-05-09 14:26 ` Alan Stern
2005-05-09 15:04   ` Adam Belay
2005-05-11  8:39     ` Pavel Machek
2005-05-09 16:57 ` David Brownell

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=200505110704.40587.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-pm@lists.osdl.org \
    --cc=stern@rowland.harvard.edu \
    /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