Darren Kenny wrote: > Alan Maguire wrote: > >> hi folks >> >> Since we're all going to be hacking away on the >> daemon, I thought it might make sense to provide >> a quick summary of the event and object model, >> and describe some stuff I think we need >> to add for NCPs/NCUs. >> >> Events: >> >> The event model is implemented in events.c. >> Events are represented by nwamd_event_t's, >> and each event is tied to a particular object type >> and specifies an event type, object type and >> optional name (certain events, e.g. shutdown >> specify no particular object). To create an >> event we call: >> >> nwamd_event_init(event_type, object_type, object_name) >> >> An example would be in the routing_events.c >> file where we create events for RTM_NEWADDR >> events associated with an interface. One key >> thing to bear in mind with NCUs - it's not >> enough just to specify the basic NCU name >> (ath0 or whatever), it needs to be qualified >> by an NCU type, i.e. ip:ath0 or datalink:ath0. >> The function nwam_ncu_name_to_type_name() >> does this, again see routing_events.c for an >> example. >> >> To enqueue an event, we call >> >> nwamd_event_enqueue(nwamd_event_t) >> >> or >> >> nwamd_event_enqueue_timed(nwamd_event_t, uint32_t) >> >> Events are dequeued in order and processed >> in the event handling thread. At present, >> object creation is carried out by enqueuing >> an INIT event for the object, and the event >> handler for that object type then updates >> the internal object list when it dequeues >> that INIT event. So in the case of enms >> for example, nwamd_init_enms() creates >> a set of events for each ENM, which >> the event handling thread catches. Then >> these events match on event object >> type (ENM) and event type (INIT) and >> call the appropriate event handling >> function - nwamd_enm_handle_init_event(). >> The tables of object/event type - to - handler >> function mappings are in objects.c, see >> enm_event_methods[], loc_event_methods[] >> and ncu_event_methods[]. >> >> External events are those that the daemon >> needs to send to listeners who registered >> to receive such events. Each event also >> has an event_mg associated with it, an >> nwam_events_msg_t. In the case that >> an event handler needs to send such >> a message, it should first be constructed >> at event creation time. Then the event is >> enqueued, and the event handler should >> call nwamd_event_send() to send the >> event_msg. >> >> Objects: >> >> Each class of object (ENM, loc and NCU) >> has it's own object list for all associated >> objects. This is manipulated via handling >> of INIT and FINI events for objects as >> described above. To add an object to >> the appropriate list, we call >> >> nwamd_object_init(type, name, handle) >> >> ...where type is NCU, enm or location, >> name is the name of the object (which, >> as specified above, needs to be qualified >> by NCU type for NCUs - ip:linkname or >> datalink:linkname) and the handle is >> the libnwam handle to the object. >> >> One other complication with NCUs >> is that we have to determine the active >> NCP. My suggestion is that we have >> an SMF property associated with the >> NWAM service, active-ncp, and when >> nwam_ncp_enable() is called, and >> does a door_call into the daemon >> to enable a particular NCP, nwamd >> sets the active-ncp property to >> the appropriate NCP name and >> refreshes. That way the user can >> persistently set the active NCP, >> and the refresh event can trigger >> a clear out of the NCU object list >> in the case that it contains the >> NCUs associated with the inactive >> NCP. Does this seem reasonable? >> Thanks! >> >> > > Alan, does this also generate an event to tell listeners that the active ncp > has > changed... > > I would think it would need to, for those cases where nwamadm was used and the GUI needed to be informed. I'll work on adding an event too and send out the details once I have something. Thanks!
Alan > Thanks, > > Darren. > > >> Alan >> _______________________________________________ >> nwam-dev mailing list >> nwam-dev at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/nwam-dev >> > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev >
