On Fri, Feb 17, 2006 at 02:27:18PM -0600, Nicolas Williams wrote: > On Fri, Feb 17, 2006 at 05:20:27AM -0500, Peter.Memishian at Sun.COM wrote: > > > > > Seems to me a possible direction for future work is to 'generify' > > > PF_ROUTE into a general kernel->userspace event reporting channel. > > > Rather than having dozens of different 'channels' (be they various > > > ioctls() that have to polled, PF_ROUTE, etc.) one extensible kernel > > > protocol could do this (there's precedent here in a certain other > > > Unix-like system). > > > > Don't we already have that with sysevents (ddi_log_sysevent(9F))? > > Sysevent consumers are limited to the global zone, IIRC.
That's not an issue, though. The event handler is dealing with system events, and will only run in the global zone. The current zones network administration model wouldn't allow any of the profiles functionality to take place in a non-global zone. If that changes, it's possible that some of the profile management could be broken out into local zones; but the event handler would still live in the global zone, distributing information to profile daemon(s) as needed. > I think we need an event system that allows for non-global zone > consumers (e.g., event ports; unfortunately it's user-defined events are > too simple as there's no way to send octet strings, structs, whatever). The only consumer of the event handler's information in the current architecture is the profile daemon. If notifications about network configuration events need to be passed on to the user, it will be done by the profile daemon. Though it's a bit out-of-date (but will hopefully be revised soon), the initial block diagram we drew up illustrates this. See http://www.opensolaris.org/os/project/nwam. -renee > _______________________________________________ > approach-discuss mailing list > approach-discuss at opensolaris.org
