Quoth Nicolas Williams on Fri, Jan 25, 2008 at 01:28:27PM -0600: > Receiving an event from the authoritative source about when the network > has been re-configured would be better. That would be NWAM, but if NWAM > is leveraging SMF then it might be SMF. > > In any case, being about to subscribe to and receive SMF events could be > very useful. > > (Alternatively, something like a refresh_on dependency could be useful > as well.)
I think you're asking for a way to tell when networking behavior matches the administrator's intended behavior. That sounds reasonable, but something for the networking team(s) to discuss. If the networking team(s) wish to utilize an SMF event channel for that, then that might also be reasonable, but I'd like to see a more detailed list of required semantics, since SMF wasn't explicitly designed for that (as far as I can tell). > > > one approach would be to use (and of course a contract > > > would be needed for this) the private libscf property group > > > notification function _scf_notify_add_pgname(), specifying > > > we want notifications for the SCF_PG_GENERAL, SCF_PG_GENERAL_OVR and ... > > This would probably work, but I'm doubtful that it's the right > > architectural direction. > > Is that because underneath _scf_notify_wait() makes a door call that > blocks in the daemon, thus using a whole thread per-waiter for long > periods of time? Yes, a more space-efficient method of event reporting > would be better (e.g., the callers pass a door to the daemon to get > called back on, or maybe just a pipe, or, if event ports can be passed > around, then an event port, ...). No, it's because nwamd would know the details of how the SMF tools communicate with svc.startd through the repository. I'd rather have nwamd listen through the interface designed for this, the restarter interface. David
