From: Tim Bird <tim.bird@am.sony.com>
To: david singleton <dsingleton@mvista.com>
Cc: David Singleton <daviado@gmail.com>, linux-pm@lists.osdl.org
Subject: Re: PowerOp Design and working patch
Date: Tue, 01 Aug 2006 11:52:37 -0700 [thread overview]
Message-ID: <44CFA2F5.1070707@am.sony.com> (raw)
In-Reply-To: <287a694aae15b3fba505f4381c95c9c8@mvista.com>
david singleton wrote:
> On Aug 1, 2006, at 3:09 AM, Matthew Locke wrote:
>>Well, no one is suggesting a user define and install that info.
>>Operating point creation will be done by someone who understands the
>>system (system designer) regardless of the method used to get the
>>operating points in the kernel.
>
> It sounds to me like they don't want to have to change kernel code and
> recompile the kernel
> to get a new operating point.
>
> It sounds like they are talking about a dynamic operating point as a
> loadable
> module, which would fit perfectly with the PowerOp scheme, since it's
> the
> system designer who would be creating the new dynamic operating point,
> not the user.
Often, in the embedded world, the person defining the operating
states will not be a kernel developer, and may not be comfortable
with, or capable of, creating a kernel module. (There are
significant sections of the embedded space where modules are
not used at all, and no module support is compiled into the
kernel.) In these cases, requiring loadable module support
for runtime OPs would be a problem.
>
> The point of PowerOp is that the system designer creates (and validates)
> the operating points that the hardware vendor supports, not the user.
>
> A system designer creating a new operating point as a loadable
> module would satisfy this requirement, and the user would not
> be able to put the system into an undefined state, either by accident
> or maliciously.
>
OK, I think I understand better your objection to user-space
created operating points. In embedded projects, it is often
assumed that no one but the system designer has access to
arbitrary user space programs. Hence, it sometimes doesn't
register that an end user could or would utilize a particular
interface, just because it existed.
Would not the normal Unix permissions system prevent the
"bad state" problem, in the non-embedded case?
-- Tim
=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
next prev parent reply other threads:[~2006-08-01 18:52 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 22:31 PowerOp Design and working patch david singleton
2006-07-28 23:38 ` Greg KH
2006-07-29 0:26 ` david singleton
2006-07-29 0:38 ` david singleton
2006-07-29 0:45 ` Greg KH
2006-07-29 5:12 ` david singleton
2006-07-29 19:07 ` Eugeny S. Mints
2006-07-30 4:43 ` david singleton
2006-07-30 11:02 ` Vitaly Wool
2006-08-01 0:59 ` david singleton
2006-08-01 10:09 ` Matthew Locke
2006-08-01 10:22 ` Matthew Locke
2006-08-01 18:31 ` david singleton
2006-08-01 18:52 ` Tim Bird [this message]
2006-08-01 18:59 ` david singleton
2006-08-01 19:17 ` Vitaly Wool
2006-08-01 19:28 ` Vitaly Wool
2006-08-06 22:11 ` Pavel Machek
2006-08-07 10:34 ` Igor Stoppa
2006-08-07 19:45 ` Tim Bird
2006-08-08 10:07 ` Pavel Machek
2006-08-08 11:12 ` Igor Stoppa
2006-08-08 11:33 ` Pavel Machek
2006-08-08 16:43 ` Tim Bird
2006-08-01 12:23 ` Vitaly Wool
2006-08-01 18:25 ` Tim Bird
2006-08-01 18:02 ` Tim Bird
2006-08-06 22:05 ` Pavel Machek
2006-08-07 3:52 ` david singleton
2006-08-07 4:17 ` Greg KH
2006-08-07 4:32 ` Vitaly Wool
2006-07-29 22:09 ` Greg KH
2006-08-01 0:36 ` david singleton
2006-08-01 1:27 ` david singleton
2006-08-07 22:06 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2006-08-01 10:09 Matthew Locke
2006-08-07 14:12 Scott E. Preece
2006-08-07 16:58 ` Greg KH
2006-08-08 13:44 Scott E. Preece
2006-08-08 13:52 ` Pavel Machek
2006-08-08 15:53 ` Matthew Locke
2006-08-08 16:03 ` Matthew Locke
2006-08-08 18:10 ` Igor Stoppa
2006-08-08 13:54 Scott E. Preece
2006-08-08 16:49 ` Tim Bird
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=44CFA2F5.1070707@am.sony.com \
--to=tim.bird@am.sony.com \
--cc=daviado@gmail.com \
--cc=dsingleton@mvista.com \
--cc=linux-pm@lists.osdl.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