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
