Re: Alternative Concept

[David Brownell <david-b@pacbell.net>]

On Monday 19 March 2007 5:03 pm, Dmitry Krivoschekov wrote:
> David Brownell wrote:
> > On Sunday 18 March 2007 1:25 pm, Dmitry Krivoschekov wrote:
> >>
> >> Sometimes it's quite reasonable to make decisions (or policy)
> >> at the low level, without exposing events to higher layers,
> >
> > Of course.  Any layer can incorporate a degree of policy.
>
> But users should be able to choose to use or do not use the incorporated
> policy, shouldn't they?

Sometimes.  What's a user?  Do you really expect every single
algorithm choice to be packaged as a pluggable policy?  Any
time I've seen systems designed that way, those pluggabilty
hooks have been a major drag on performance and maintainability.

Most components don't actually _need_ a choice of policies.


> > It's only when that's badly done -- or the problem is so complex
> > that multiple policies need to be supported -- that you need to
> > pull out that old "mechanism not policy" chestnut, and support
> > some kind of policy switching mechanism (governors, userspace
> > agents, etc) for different application domains.
> >
> >
> >> e.g. turning a clock off when reference counter gets zero, this is
> >> what OMAP's clock framework currently does.
> >
> > There are no choices to be made in that layer; it's no more "policy"
> > than following the laws of arithmetic is "policy".  Software clock
>
> there is some principle: "turn the clock off when use counter reaches
> zero", so it is a policy, and a choice is to disable or not to disable
> an output clock, it is the simplest case but it's certainly a policy. 

That's not a choice; it's how the API is defined.  It's not "policy".

Arithmetic is defined so that 2 + 2 == 4.  Should we have a "policy"
allowing it to == 5 instead?  Or should we just accept that as how
things are defined, and move on?

At some point, decisions are just ground rules, and not policy.

- Dave