On Fri, Jan 25, 2008 at 03:07:39PM -0800, Liane Praza wrote:
> David Bustos wrote:
> > 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.
>
> The version of this for administrators, who may want something
> higher-level than a C API is filed as:
>
> 6577813 SMF should natively support actions (snmp trap, script,
> email) on service transition
>
> liane
I wouldn't necessarily assume those are the same thing. The above thing
can easily be satisified by an asynchronous queue of outbound notifications.
The thing that is needed for NWAM may require something synchronous.
One question I had is whether this can't be solved more simply by just
having the start/stop methods call a command that does a door_call
to nwamd to indicate what is going on, e.g. in the middle of your script:
nwam -notify $SMF_FMRI $SMF_METHOD
or whatever. Anyway, I would start by deciding if you need this to
be synchronous or not.
-Mike
--
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
