On Thu, 10 Mar 2005 10:51:27 +1100 "Nigel Cunningham" <ncunningham@xxxxxxxxxxxx> wrote: > Hmm. I agree with having policy in userspace, but the question is, how > much. I've been thinking that the _setting_ of policy belongs in > userspace, but the _implementation_ of policy belongs in the drivers. > If that's the case, then events that affect the implementation of > policy - such as this example - would need to be able to come from > userspace. I can see sense in your argument, but it also causes me to > rethink that distinction. Perhaps the setting of policy belongs in > userspace, and the implementation of policy belongs in the drivers in > some cases, and in userspace in others. But if we go down that path, > don't we complicate matters when it comes to run time power > management? I favor implementing the policy in the drivers - after all, its the driver that knows the most about the device. This is especially true if we start talking about inactivity timers, and wake on event - it will be much more efficient to let the device transition its state in these situations then passing up the event to the user space and letting the user agent handle it. But I do think that we need to provide for the user land to change the policy quickly based on system events, and I think that we can reliably expect that the driver will obey. Basically, I guess I'm trying to say that the drivers should be somewhat capable of implementing policy, but they should always defer to the user, who presumably, knows best. Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group <www.amd.com/embeddedprocessors>
