On Thu, Mar 06, 2008 at 05:18:24PM -0500, James Carlson wrote: > I've read through this thread: > > http://opensolaris.org/jive/thread.jspa?threadID=47134&tstart=15 > > and I'm still quite confused about this issue. If there's some > consensus about which direction SMF is going, I'd like to know about > it. > > I'm currently working on an Ethernet bridging daemon for Solaris. > It's not part of NWAM, but it looks like the problems I'm facing are > somewhat similar. I'd like to try to make it conform to SMF as much > as possible. This means storing the configuration data in SMF, and > representing the instances using SMF instances. > > For symmetry with other networking tools and other administrative > interfaces, I'd like to be able to allow for "temporary" changes -- > ones that intentionally do not survive reboot. This means being able > to create bridge instances temporarily, add or remove links > temporarily, and so on. It seems like just good system administration > to be able to address the running configuration or the saved > configuration at will. > > This runs me directly into a problem: SMF doesn't allow for the > creation of temporary instances, so addressing only the running > configuration isn't possible. It looks like the acceptable solutions > are: > > - "mws mode" > > When the user specifies "-t", have the command line tool invoke > the daemon directly rather than creating a new instance and > enabling it (as we would ordinarily do). This causes a host of > design problems: > > . The user must have sufficient privilege to actually run the > daemon, where all he needed in the normal case was privilege > enough to create the instance and enable the service. We > lose the benefits of the privilege tie-in for regular SMF > services (svc.started?). > > . The code in the utility that handles "-t" will need to be at > least twice as complex. Instead of just knowing how to > manipulate the SMF bits, it'll also need to know how to > launch the daemon and feed it data that the daemon would > ordinarily get directly from libscf on its own. > > . The code in the daemon also needs to be more complex and > ad-hoc. Instead of reaching out to get the data from libscf > when needed, it has to "listen" (doors?) for someone else to > supply the data through some other channel or needs to fetch > it from stdin or command line arguments. > > I don't think I can solve those problems in any clean way. I > realize that it follows the "ifconfig versus /etc/hostname.*" > model, but it looks like a mess to me. > > ... > > I'm leaning towards the second solution (the work-around) or perhaps > the fourth (sorry, no temporaries), but I don't like either of them > much.
Is a bridge instance a separate instance of the daemon or one of a set of things that is managed by one daemon? (i.e. that could be represented by a property group rather than an instance) -Mike -- Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
