Re: [Cpufreqd-devel] interrupts as source for cpufreqd rules

[<aer...@fa...>]

<..>
> > In my mind I brought it a bit further than that. In essence cpufreqd 
> > does:
> [...]
> > /* "policy" function */
> > interactive() = (interrupt[12] + 20*interrupt[1]) >10 ? 1:0;
> > 
> > f()=(interactive()>0 ? "perfomance" : "powersave";
> > g()=(interactive()>0 ? 500 : 200;
> > h()=(interactive()>0 ? 10000 : shell("/bin/myfunc");
> 
> well, this is straightforward to me, but I suppose not to the average
> user.
> Things I'm concerned about:
> 1- cpufreqd ease of use (would the average user be able to configure it?)

Hmm, I guess you have a point there. Otoh, I (as a user) had problems
with the current approach, since the rules didn't alow me to implement
the policy I wanted. I guess it's two aspects of the same problem.
Either we make the rules flexible enough to harness all apsects of the
problem domain (which can make it tricky for users to "get it"), or we
make the rules "dumber" thus making it so that the casual user can
make it do something approximating what he wanted to do (but running
the risk of not allowing him to ever "get it right").

I guess some well written examples could get users in the right
direction...

> 2- cpufreqd processor usage (a program aiming at power saving can't be
>   power greedy)

Agreed. But how much is too much? If the above is fed through lex/yacc
we could have a compiled output as a result of the parser which we
link and call. I wouldn't expect the #cpu cycles spent in that call to
be too much. Doing the lexing and yaccing in the first place would be
noticeable though, but that's a onetime penalty.

> 3- I don't know how much this would integrate with the plugin structure I
>   have in mind (my first assumption is that plugins are responsible for
>   providing their own config directives - like the apache web server
>   plugins do)

I'm not quite sure what the plans are for the plugin structure.... I'd
assume a plugin such as the interrupt[] thing, would have to supply
info to the lexer to extend the set of known tokens. Apart from that I
guess we'd call _all_ plugins and have the right values ready when
evaluating the expressions? (Another approach could be to have the
plugin cache values for some time, thus lowering the penalty for
multiple calls to the same plugin for a given run. In the above case
interupt[12] is asked for three times...). What else have I missed?



> Anyway I like this approach and I'd like to restructure configuration
> too. Let me think some more about it. (BTW: suggestions are welcome)
> 

By all means. I just had a glance at a lex/yacc book, and it mentioned
that bc (the calculator) used lex. It might be worthwhile to steal
some lex/yacc code from it for the evalualtion function...


> > Adding new information elements to such a framework would be
> conceptually straightforward. Writing the necessary bits to evaluate
> the expressions i not fun (nor trivial) though. I have a feeling
there
> should be some lib available which should be possible to use,
though.
> (The mh mailer has a rather similar thing to parse its config files,
> where you can use 'if-then-else' clauses on source mails to compose
> the headers for the reply mails. Might me woth looking into...)

flex (http://lex.sourceforge.net/) or bison (from FSF). It should be
quite easy to create the rules with such a tool. But remains point 3
above.

 Yep. I'd say point 3 should be fixable. Maybe point 1 is more
critical to 'get right'?


> thanks
> -- 
> mattia
> :wq!
> 

BR,

/Anders