Quoth Nicolas Williams on Fri, Jan 25, 2008 at 04:30:32PM -0600: > I gave a specific example, but I think that a non-polling way to learn > about SMF service state changes is important. I think that because in > general non-polling interfaces by which to discover various system state > changes are useful.
I agree. Please file an RFE. > I don't see why a neatly packaged interface for asking restarters (or > svc.configd) for state information would be the same thing as exposing > implementation details. I don't either. There's already an interface for asking restarters about the state of a service: smf_get_state(). If you're talking about state other than the SMF state, there is the auxiliary_state property, but beyond that will have to be restarter-specific (currently). But that's not what we were talking about. Alan wants nwamd to observe the commands which administrative tools issue for services. The design assumes that you only want to do that if you're the service's restarter, and then you should use the restarter interfaces. If there are cases where non-restarter components need to do that, then we need to consider whether the existing interfaces can be expanded, or a new interface designed, or perhaps even the implementation of SMF tool / svc.startd communication exposed. > Also, I think that limiting event consumers to restarters, and further > limiting them to learn only about the state of their spawn, is just > too... limiting. Why constrain these interfaces so? Or did you mean > something else? If you know of a case where it would be useful for a non-restarter component to observe events other than the state, then please file an RFE. David
