* Peter Memishian <peter.memishian at Sun.COM> [2006-09-27 11:57]: > > > > Well, why not consider stability a low-level feature? That is, why would > > > it be wrong to have the low-level interfaces grok the notion of > stability, > > > and (e.g.) require specific flags to modify unstable properties? This > has > > > the side effect of forcing all developers to confront and address the > > > notion of stability when writing their software. > > > > Whenever I think about promoting stability in smf(5) from an > > informational attribute to an active policy, I usually go down the > > path of suppressing the visibility of less stable levels in the output > > of svccfg(1M) and svcprop(1). Could you expand on why you think > > modification alone is a suitable enforcement point? > > Supressing visibility by default also seems like a good thing -- but of > the two sins (showing properties that shouldn't be touched, and allowing > unstable properties to be modified by default), modification seemed the > more serious offense and thus I preferred that argument. I think I prefer to combine the two; a person is probably looking at the implementation properties with the intent to change them (possibly unwisely or as an experiment). > In both cases, the notion of placing the enforcement inside the tools > rather than making it part of the API *does* concern me, though. While > there may be cases where tools should allow modification or visibility of > unstable properties without warning the user, I think those tools should > still have to do so consciously -- e.g., by passing the appropriate flags > to the underlying library routines.
That's fine: the libscf API is handle-based, and the handle can be appropriately annotated by default. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/
