On Mon, 2009-01-26 at 10:03 -0500, Sowmini.Varadhan at Sun.COM wrote: > On (01/26/09 09:50), Sebastien Roy wrote: > > While it could be considered, I think it would be too risky a change > > even for a Minor release, and maybe even for a Major release. I don't > > think it would be acceptable to require 3rd party software to be > > modified to undo unwanted persistent configuration. > > Or we could disallow the mix/match of ifconfig and ipadm. > ifconfig would only be able to do temporary changes, and ipadm only > does the persistent ones.
Sure, but my supposition was that we were building a system in which ifconfig becomes obsolete. Is that not the case? I think I've lost track of what the initial problem was. What is the problem with ipadm being able to manipulate both temporary and persistent configuration (either at the same time, or individually), and having ifconfig stay the way it is? Humans configuring the system using ipadm may benefit from having it operate on both the running system and the persistent configuration by default (and that makes sense given that dladm and SMF commands operate this way), but that doesn't mean that we should throw its ability to operate strictly on the running system out the window. > In order to achieve this, the library would have to support both > temporary and permanent settings. And to enforce it, the library > would have to track the "temporary/permanent" status of the > underlying object. > > Or we could just have all ipadm/ifconifg operations on > interfaces to be temporary (only the interface-agnostic operations > on the tcp/ip module itself would be persistent), and > implement one single method for persistence thorugh libnwamd. That's an interestingly different tack on the problem. I'm not sure how NWAM fits in with this yet, but I had assumed that NWAM was a consumer of the interfaces provided by this project. -Seb
