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 --]
next prev parent 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 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.