Mike Shapiro wrote: > 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. > So, we treat temporary network configuration differently than persistent network configuration here. If you create a temporary network configuration, you won't see the smf instance for it, thus, you won't be able to operate on it with any svc tools.
For example, if you create a persistent aggr, you can see network/datalink:aggrx in the svcs output and you can disable/enable it using svcadm command. But, if you create that aggr temporarily, you won't be able to see it in the svcs output. Thus, there is no way to disable/enable it w/ svc tools during its life time. I'm wondering if it is acceptable in the long term? Max > -Mike > >
