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... Thanks, Darren. > Alan > _______________________________________________ > nwam-dev mailing list > nwam-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-dev
