Re: [RFC] PowerOP, PowerOP Core 1/3

[Pavel Machek <pavel@suse.cz>]

Hi!

> >>+/* 
> >>+ * powerop_register_point - add new operating point with a given name to
> >>+ * operating points list. A caller passes power parameters for new 
> >>operating
> >>+ * points as pairs of name/value and passes only those parameter names 
> >>the
> >>+ * caller is interested in. PowerOP Core calls powerop driver to 
> >>initialize
> >>+ * arch dependent part of new operating point and links new named 
> >>operating + * point to the list maintained by PowerOP Core
> >>+ * 
> >>+ *
> >>+ * INPUT
> >>+ *   id         - operating point name
> >>+ *   pwr_params - set of (power parameter name, value) pairs
> >>+ *
> >>+ * OUTPUT
> >>+ *   none
> >>+ *
> >>+ * RETURN
> >>+ *   zero on success, error code otherwise
> >>+ *    
> >>+ */
> >>+int 
> >>+powerop_register_point(const char *id, const char *pwr_params, ...)
> >
> >kzalloc?
> >
> >Why do we want one more string parser in kernel?
> >  
> referencing power parameters by name  interface is result of  gradual 
> evolution of PowerOP interface mainly in order to address the 
> requirement to be truly arch independent interface and to get rid of 
> sharing an arch dependent data structures (a structure which defines 
> operating point for a certain platform) between layers on top and 
> beneath PowerOP (see the picture of the layers; thus a layer which 
> creates operating points with help of PowerOP don't need to include arch 
> dependent definition of operating point structure from PM Core layer). 
> The latter fixes the overall PM architecture with OOP design concept.

We need better solution. Putting string parser into kernel because you
feel OOP is nice is bad idea. See vfs for example of OOP-like design
without string parsers.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html