Quoth Alan Maguire on Mon, Jan 28, 2008 at 08:55:56AM +0000: > one consequence of this would be that network/physical:default > would have to be changed from a transient service to a > delegated restarter, but that makes sense too i think, since > it will also control the datalink and IP instances.
Right. After thinking about this some more, I've come to a similar conclusion. First let's understand what a restarter is, abstractly. A restarter is code which implements the standard SMF administrative interface for a service. The first half of that is translating the service's states into SMF states. For services implemented by daemons, we know that if the daemon hasn't been launched into a process, then the service is not online. If there is a process, then we presume that the service is online, though really we should use a service-specific liveness test, which is what the to-be-designed "monitors" are all about. The second half is implementing standard SMF commands from the administrator, such as enable, disable, refresh, degrade, maintenance, milestone. We start and restart services implemented by daemons by fork()ing and exec()ing them, and usually kill the processes to stop them. Now it seems that you want two distinct administrative behaviors for your datalink services: one with NWAM, and one without. If I understand correctly, you're planning on implementing the non-NWAM behavior by configuring the "transient" model of the svc.startd restarter. And you wanted to place the NWAM code into a daemon, which essentially needs a way to interpose itself between the SMF administrative interface and the implementation thereof, i.e., the restarter. I suggest that we think about what you're trying to do more as a modular restarter. That is, under some circumstances you want relatively plain administrative behavior, but when NWAM is enabled, you want more sophisticated behavior. Restarter switching was designed into SMF, but it was seen as something administrators would choose on a service-by-service basis, and it hasn't been implemented anyway. But it wouldn't be a good fit anyhow because you want a single action (enabling NWAM) to switch the restarter on a whole class of services. Another way you could implement this, though, would be to have your own restarter which was capable of implementing either the plain behavior or the NWAM behavior, and switching as necessary. I think this fits better into the SMF design. Note that you could still place the NWAM code in a separate daemon, but it would have to communicate with the code which is designated as the restarter. I suspect that a loadable module might make more sense, though. One issue that comes to mind is that we don't have a standard way for a restarter to advertise which behavior it is using for a service, though that's also an issue for svc.startd's three models and we haven't had any big complaints from administrators. If we can agree that this is the right long-term plan, then we can discuss whether we should make changes to SMF to make this easier, and whether we should opt for cheaper designs or implementations in the short-term. David
