> On Tue, Dec 05, 2006 at 08:57:38AM -0800, Michael Shapiro wrote: > > > You're not missing anything: the use of const in this family of interfaces > > is totally busted and makes them impossible to use without casting. > > > > Basically just cast away the const from any return values. > > scf_simple_app_props_next() has the same problem. We need to figure out > > whether we should un-const these or whether it would be better at this > > point to EOL (but keep for binary compat) and replace these interfaces. > > I've filed: > > 6500842 scf_simple_prop_next_*() prototypes incorrect > 6500843 scf_simple_prop_next_*() can't be used for results of > scf_simple_app_prop_next/search() > > > My personal view, having written quite a bit of code using the lower- > > level interfaces, is that we should replace scf_simple_* because I don't > > think > > they offer the kinds of simplification that is actually useful. > > scf_simple_prop_get() is pretty handy though.
I don't even like that one, because you still have to: - check the type - check the number of values - deal with the odd signatures of the various simple_prop_* functions to get your values back If you compare that to using the lower-level interfaces, you'll realize that there isn't much simplification being offered beyond create/destroy of handles. A much more useful set of primitives for the truly simplest queries would be: - for each primitive type, a function which retrieves a property given handle, instance, pgname, propname, and expected type, and returns me the single-value directly or an error - an interface which permits me to declare an array of such descriptions and then iteratively fills in a C struct with the result of each, allowing easy retrieval of a small set of single-valued properties -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
