2007/393 converting /etc/default/{nfs,autofs} to SMF properties

Glenn Skinner glenn.skinner at sun.com
Tue Jul 3 14:34:06 PDT 2007


    Date: Tue, 03 Jul 2007 14:55:22 -0600
    From: Robert Thurlow <robert.thurlow at sun.com>
    Subject: Re: 2007/393 converting /etc/default/{nfs,autofs} to SMF
	    properties

    Glenn Skinner wrote:

    > Perhaps I missed something along the way about how SMF properties
    > are used in practice.  But why are the properties above all
    > represented as astrings when SMF supplies more precise types such
    > as integers and booleans that, presumably, are more appropriate
    > for many of them?

    The key consumer of these properties is the NFS plugin to libshare,
    libshare_nfs.so, which per the libshare architecture reads all
    properties and composes an XML document in memory to make them
    available to libshare.so.  By making everything-an-astring, we get
    the simplest mapping to XML and simple bulk-loads and -stores to
    SMF.  This use of XML means that libshare.so need not worry about
    the type of any attribute, leaving all details to the plugin.  The
    plugin is also responsible for error-checking when properties are
    set, and does so now by manipulating string properties.  Finally,
    all of our old def_read() consumers are used to dealing with
    strings; we don't know yet if we will have them call libshare.so or
    SMF directly.

This still strikes me as an abuse of SMF, especially since the proposed
stability level for the properties is Committed, which implies that
they're intended to be visible directly through svcprop(1) et al (as
opposed to being intended to be manipulated only through sharectl et
al).  Access through svcprop ought to apply proper type checking, which
won't occur if the types are all astring.

Given that, do you really want these properties to be Committed, or
would Project Private be more appropriate?

(It would be interesting to hear what the SMF team thinks about this
choice of representation.  Have you checked with them?  It certainly
seems like the enhanced templates project could help here.)

		-- Glenn




More information about the opensolaris-arc mailing list