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