BTW, I forgot to mention one neat side-effect of using sysevents would be that we could use the sysevent DTrace provider to snoop on nwam event notifications. This would likely be helpful in diagnosing bugs, and we could add an nwam event notification listener to the DTrace example scripts.
Alan Alan Maguire wrote: > hi folks > > I've been looking at implementing the event > notification mechanism for phase 1, where > interested clients such as the GUI apps > and the commandline UIs register for > notification of events of interest from > nwamd (e.g. got an IP address, switched > NCPs etc). The current code utilizes doors > as the backend IPC mechanism between > clients and the daemon, but while this > approach is good for the single-client > case, it's more complex as we scale > up to more clients (the daemon has > to keep track of these multiple clients > and hold onto notifications for events > that occurred at time N until all clients > registered before time N have been > notified or have gone away. > > It seems to me that sysevents might > be a good fit for dealing with this problem - > i.e. the client (via libnwam) binds > and registers for NWAM-specific > sysevents pertaining to autoconfiguration > state. One problem with this - I believe > there's a bug in that sysevent_[un]bind_handle() > requires a uid of 0 to complete successfully > (the right fix here, I think, is to add privs > and auths to add to the console user profile > so it can bind and receive sysevents). Otherwise, > I think we'd end up reinventing a similar > mechanism. What do people think? Is this > a reasonable approach? (I'd estimate it'd > take about a week to implement this). > Thanks! > > Alan > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
