| From: Pavel Machek<pavel at ucw.cz> | | On Sun 2006-09-03 17:12:22, Scott E. Preece wrote: | > | From: Pavel Machek<pavel at ucw.cz> | | > | > But, surely that distinction can be handled in the implementation behind | > | > the interface, rather than exsposed in the interface. Does that | > | > distinction matter to the policy manager? I would argue that it | > | > increases the latency, which would be important to the policy manager, | > | > but that the nature of the latency isn't important to making a policy | > | > decision, and the proposed interface already exposes the latency as | > | > something that can be used in making transition decisions. | > | | > | Are we talking about the same thing? | > | | > | If policy manager decides to suspend-to-RAM, it will freeze | > | itself. Puff, it is not running any more. | > --- | > | > Well, I assume the policy manager is telling something in the kernel to | > actually set the operating point. Once it has made that request, it | > doesn't need to run any longer. | | And how will it tell the kernel to get back to some _operating_ | point? (As opposed to "off-suspended-to-disk"?) | | You see, that interface even causes problems in our (human!) | comunication. Some of operating points are not really operating! --- You mean, how will it initiate the transition out of "suspended"? Well, obviously, it wouldn't be able to do that until the machine resumed. But, from the perspective of the policy manager, that doesn't really matter - no time passes (from its perspective), it just starts running again, receives some kind of wakeup event from the kernel, and decides what transition should happen. --- | | > | Of course, we could use same interface for both. No, it is not good | > | idea. We want reasonably clean interface. If it means rewriting | > | powerop two or three times... we'll need to do it. | > --- | > | > Not speaking to either of the current code submissions, I would say that | > having a kernel interface for defining OPs and a kernel interface for | > setting the OP, was a reasonably clean interface. | | Well, me and Rafael disagree, and you do not really listen to | arguments. Now you can either fix the interface, or try to submit code | to lkml despite our NAKs. Go ahead and prepare for some flaming... --- I think I'm listening to arguments just as much as you guys are! We just disagree. What are your criteria for "a clean interface"? Why do you think that n separate set-parameter() interfaces, with no consistency relationship between them, are cleaner than one define-op() and one set-op() interface? scott -- scott preece motorola mobile devices, il67, 1800 s. oak st., champaign, il 61820 e-mail: preece at motorola.com fax: +1-217-384-8550 phone: +1-217-384-8589 cell: +1-217-433-6114 pager: 2174336114 at vtext.com
