One wrinkle on this design suggestion - I'm now thinking sysevent eventchannels would be more suitable. That way, NWAM events would have a dedicated channel rather than being part of the global sysevent queue. Responses inline below...
Darren Kenny wrote: > Hi Alan, > > Alan Maguire wrote: > >> hi folks >> >> I've been looking at implementing the event notification mechanism for phase >> 1, where interested clients such as the GUI apps and the commandline UIs >> register for notification of events of interest from nwamd (e.g. got an IP >> address, switched NCPs etc). The current code utilizes doors as the backend >> IPC mechanism between clients and the daemon, but while this approach is >> good for the single-client case, it's more complex as we scale up to more >> clients (the daemon has to keep track of these multiple clients and hold >> onto notifications for events that occurred at time N until all clients >> registered before time N have been notified or have gone away. >> > > Understood... > > >> It seems to me that sysevents might be a good fit for dealing with this >> problem - i.e. the client (via libnwam) binds and registers for >> NWAM-specific sysevents pertaining to autoconfiguration state. One problem >> with this - I believe there's a bug in that sysevent_[un]bind_handle() >> requires a uid of 0 to complete successfully (the right fix here, I think, >> is to add privs and auths to add to the console user profile so it can bind >> and receive sysevents). Otherwise, I think we'd end up reinventing a similar >> mechanism. What do people think? Is this a reasonable approach? (I'd >> estimate it'd take about a week to implement this). Thanks! >> > > This sounds fine - the main thing for us (the clients) is that the actual > mechanism isn't exposed - which I believe is what you're suggesting. > > Exactly. You don't see the underlying mechanism at all - an event client simply registers a callback function which will be called when events occur. > From my (admittedly poor) understanding of sysevents, they are quite "sparse" > in that they don't contain a lot of information, so I would presume that we > would receive an event, and then, should we need more information (e.g. > Scanned Wlans) we would make a call via libnwam which is likely to use doors > to get the information. > > Is that correct? > > Or would it be more likely that this would happen under the > cover in libnwam itself, and when an event is dispatched to the client it > would already contain this information? > > I suppose what I'm really asking is how exactly this change effects the UI, > since it's really an implementation detail that shouldn't cause impact on the > UI's use of the libnwam APIs... > > Nothing should change - the idea is that sysevents (whether from the global sysevent mechanism or a specific event channel) have an nvlist attribute list. libnwam's event dispatch function - which only nwamd uses - nwam_event_send(nwam_event_t e) will package up an event as an nvlist attribute list and dispatch it. Then the user-supplied callback - which the user specifies as an argument to nwam_events_init() - will be triggered on receipt of an nwam sysevent. Our wrapper callback function will convert the nvlist attribute list back into an nwam_event_t (formerly an nwam_event_msg_t) and call the user's callback function with it as an argument. So the attribute list can actually contain all the information we need. BTW I think the current nwam_event_t structure might need a few additions - I'll follow up with those as I find them. > From what I've seen in the commit messages, you seem to have fixed the > requirement of a uid of 0 - so that should remove any related issue on the UI > side as long as the necessary auth is in the default set for Network > Autoconf... > > Yep, I believe so (and I added the auth to the console user profile too). Thanks! Alan > Thanks, > > Darren. >
