> Tomas Zeman wrote: > > Hi Mike, > > > > On Sun, Jul 29, 2007 at 06:33:59PM -0700, Michael Shapiro wrote: > >> The top-level question to ask is whether plug-in configuration is (a) > >> intended > >> as tunables for administrators or (b) really only for developers or for the > >> "I'm a Solaris OEM" level of customization. For example, for fmd(1M), I > >> have > >> a set of plug-ins, but the architecture is entirely oriented around (b). > >> Therefore, for fmd, plug-in delivery and config is handled entirely > >> outside SMF. > >> If your answer is more (a), then property groups is likely the best > >> approach > >> because you have to control the plug-in namespace anyway, so you can just > >> mirror that namespace in the property group layout. > > > > Yes, plugin configuration is (a), intended for administrators. I expect > > they'll > > be enabling/disabling plugins and changing their configuration as per site > > policy. > > and eventually 3rd party plugins are expected to be developed and > shipped separately to Solaris as well. Once we open up the plugin API.
Based on what you've said, I'd suggest defining a module namespace with a 1:1 mapping to the property group namespace, and some means of publishing the properties into SMF as part of the module delivery. One design choice here is whether you permit developer-defined properties, which would require you to do something like deliver an XML fragment (<property_group> decls) with each module that you slurp in to set up the SMF groups, or whether you have a standard set of properties defined by the framework. I'd encourage you to limit the amount you expose to administrators initially. The design center should be that people can enable auditing without setting knobs. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/