On (01/10/09 14:35), Alan Maguire wrote: > This looks fantastic - the uncluttered output > from ipadm show-address is particulary nice.
thanks! > There are a few things I'm wondering about > though. You mentioned SMF a few times, and > in section 2.6.3 (persistence of properties), > you mention that an explicit call to ipadm init-prop > may be needed to consult the persistent store to > reapply properties (likely initiated in network/physical's > start method). Would it instead perhaps make > sense to delegate the initialization to SMF representations > of the IP interfaces themselves, e.g. when I > run "ipadm create-interface bge0", it would > create a SMF instance svc:/network/ip:bge0. The > start method of that instance could then do the > initialization on a per-interface basis, i.e. run > "ipadm init-prop bge0". The per-interface properties > could be stored at the instance level, while global > IP tunables could be stored at the service level > (svc:/network/ip) and overridden (if appropriate > for that tunable) at the IP interface instance level. > Then on reboot, the persistent nature of the SMF > instance would ensure initialization happens. This is a good idea, but as you suggest later, I think we can (without loss of generality) consider the details of the implementation of the persistent representation itself to be private, and switch to SMF later, as long as we make sure that we are not placing any constraints on suggestions such as the above. > > Also, I'm wondering about the distinction that > dladm (as I understand it at least) makes between > state, temporary configuration and persistent > configuration. Do we need an equivalent "-t" > option for ipadm options, which creates > a configuration representation in storage > that however does not persist to the next > reboot? (This currently isn't possible with > SMF - assuming that the representation would > consist of IP interface instances as I suggest > above - but I believe the extended profiles > project will help here). Erik and I talked about this (see previous mail in this thread at http://mail.opensolaris.org/pipermail/brussels-dev/2008-October/001059.html I think we can always add -t later on, if the need is felt, but if we allow -t switches for the interface commands, there's the issue of resolving dependancies between the commands that Erik points out. --Sowmini
