Stephen Hahn wrote: > This is pretty cool. What do you see as next steps?
Glad you like it. From our perspective, it's pretty much done - it meets our requirements, and we don't have a requirement (or funding) to make it general-purpose. The first couple of things I'd do to improve it would be: - Add "svccfg inventory". (That would let us get rid of one or two of the few remaining platform-specific bits in our admin tool and installer.) Not sure about other svccfg commands - it doesn't need import or delete, since it operates by reading the manifests directly. The property manipulation stuff might be appropriate if somebody wanted to support an application that used it for configuration - ours doesn't. - Add svcs. People (our QA and development) keep asking about it, even though SMFlite isn't part of the public interface to our product. Both of those are pretty easy. The two biggest gaps are also the two hardest to fill: - Health monitoring. Absent contracts, seems doomed. Note that this limits the usefulness of svcs, though it would still be useful for displaying state and detecting startup failures. - Better isolation from invoker. Currently everything is a child of the invoker (that is, the process that says "svcadm enable" or "svcadm boot"), with all of the potential headaches associated with that. It makes some attempt to break the ties, but the true-SMF answer of actually starting everything from the daemon seems much better. (Even without it, centralizing the "daemonization" helps.) My overall inclination isn't to try to duplicate 100% of SMF. That's too much work, for too little payoff in this case. Instead, I want to do the 10% of the work that yields 80 or 90% of the functionality. That's certainly plenty for my group's purposes, and I think it's probably plenty for wider compatibility purposes. As I noted, if somebody ever puts contracts into the Linux kernel, it'd probably be better to just port real SMF.
