On Fri, Jan 25, 2008 at 10:26:11AM -0800, David Bustos wrote: > Quoth Alan Maguire on Thu, Jan 24, 2008 at 07:04:12PM +0000: > > under the SMF datalink/interface networking model we've > > been discussing here and elsewhere, SMF instances will > > exist for datalinks and IP interfaces. one problem with this > > is that the policy engine handling such instances, e.g. NWAM, > > would like to receive notifications of adminstrator-driven events > > such as disabling the instance or refreshing, while not taking > > full responsibility for managing the instance (as a delegated restarter > > would - NWAM can't be a delegated restarter since the datalink/IP > > interface instances exist whether NWAM is enabled or not). > > Has this been discussed elsewhere? I would like to understand what you > require that we don't provide.
Well, we're likely going to add code to use a PF_ROUTE socket to detect network re-configuration events in idmapd(1M), and other daemons (e.g., smbd, nscd, ...) already do this. But receiving a PF_ROUTE message != network re-configuration is complete. For example, an interface may have been brought up and configured, but static routes not yet added, and there's no way to know when all relevant routes have been added. 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.) > > 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 > > SCF_PG_RESTARTER_ACTIONS property groups. placing notifications on > > the first two catches enable and disable events, persistent and > > temporary. notifications for SCF_PG_RESTARTER_ACTIONS catch > > refresh, restart, maintenance, clear events. we can then use > > _scf_notify_wait(), fish out the FMRI and handle the event. > > does this approach have drawbacks? is there a better way to > > catch such events? thanks! > > 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, ...). > Let's determine what's missing in the > delegation model and how expensive it would be to fill it in before we > go too far with this. Sure. Nico --
