> > > >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.
Correct. > 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 It is no different than any other system abstraction, as in my example for daemons. SMF state represents the administrator's intent to create some persistent settings, and thereby delegate management of the corresponding abstraction to the associated SMF restarter. But SMF is not a substitute for the underlying kernel subsystems: people are permitted to start processes outside of SMF, instantiate pools outside of SMF, type ifconfig outside of SMF, and so forth. And those subsystems will always offer some underlying primitive to create and manage their resources: such primitives are required to implement the SMF code itself, and also for layered applications, developers, debugging, and so on. That is as it should be. Typing "svcs" asks SMF to tell you about the resources it owns: i.e. the things you told it to do. This is not the same as typing "ps" or "ifconfig", which are asking the kernel to tell you about all of the processes or all of the net interfaces and so on. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
