hi Sowmini Sowmini.Varadhan at Sun.COM wrote: > To revive this thread: I summarized all the comments > exchanged in this thread, along with subsequent 1x1 discussions > with a couple of folks at > http://opensolaris.org/os/project/brussels/files/brussels2.pdf > > Some interesting topics for discussion are on how to deal > with current methods for configuring interfaces particularly > using the network/physical:default service, and also how > to organize the current "flags" related info dumped out > by ifconfig in some useful way.. I've put out some thoughts > there- comments/opinions are invited. > > This looks fantastic - the uncluttered output from ipadm show-address is particulary nice.
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. 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). Of course, assuming that the persistent representation of IP interface data is private, it would be possible to deliver ipadm and later migrate to an SMF representation of IP interfaces. Alan
