On Wed, Dec 19, 2007 at 09:27:40PM -0500, Peter Memishian wrote: > > > Or, for now, we choose not to create any smf instance for temporary > > configuration. We only represent persistent configuration via smf > > instances. Thus, we don't have to worry about removing them during next > > reboot. And we'll add temporary configuration support later when we have > > some support from smf framework to handle such temporary instance. But, > > the questions here are that: > > Is this an acceptable way to represent networking configuration? > > Do we have any plan to add temporary instance support in smf framework? > > FWIW, as I stated at the meeting, I fear this approach *is* unacceptable > in the long-term, because it means that the administrator (or tools) can > no longer rely on SMF to provide the current state of these system > services. The result is that the SMF representation of IP interfaces and > datalinks becomes only meaningful as an implementation convenience for > tools such as NWAM, which was one of the things that mws was vehemently > against in the original Clearview UV SMF proposal. > > Put differently: if the intent is for each configured IP interface or > datalink to be represented in SMF, then that needs to be visible in SMF > regardless of whether it will persist across reboot. If that's not the > intent, then I'd like to understand what the intent is. If SMF doesn't > provide the functionality necessary to do what we need, then it should be > extended rather than compromised. > > -- > meem
SMF should not support such temporary instances. SMF is not a replacement for every kernel state machine. Creating temporary network mods is the mental equivalent of starting a daemon outside of its smf instance -- it works, you can do it, etc. but it is not reflects in your svcs output. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
