> I'm still not connecting the final dots here to my question. When dladmd > starts, how does it perform the association of its persistent state > [ vanity-name, linkid ] to the device that was attached in the kernel? > You must have persisted also the device path for this as well, right? > i.e. so that you can go create the datalink named <vanity-name> out of > that device and assign it the corresponding linkid by poking the kernel? > Instead of persist the device path, we persist the device instance name - <driver><[ppa>. But yes, you got the idea.
> That aside, here is the larger issue: in my view we need to move Solaris > networking to a model where individual datalinks and interfaces are > represented > by SMF instances (*not* one big blob, network/physical, *not* things inside of > another big blob). The reasons for this are manifold, but some of them are > that the individual objects themselves can fail or be misconfigured > independently, and SMF expresses a state machine at the instance level. > With things hiding inside of the blob, we can never leverage any of the SMF > infrastructure to express those failures to administrators (e.g. svcs -x, > future event notification through FMA), nor can we leverage many of the > other obvious per-instance operations, like svcadm disable/enable/refresh. > > The model for this is in effect the strategic roadmap that needs to be > developed for both NWAM and vanity naming and other things. The schema for > this representation is the big unanswered question here, and it has a major > impact on how you approach persistence of vanity naming. For example, one > can observe that if a persisted datalink has an instance name, then a rename > of the persisted datalink needs to go rename the SMF instance. > > The reason for my question around the daemon is really that I'm trying to > understand if you're solving the above problem, precluding its solution, or > perhaps moving us a step closer to its solution but not going all the way > there. I think based on what I've heard we really need to answer this root > question first: what is the SMF model for datalinks and interfaces. Once we > do that, the details of vanity naming's persistence model can be evaluated > against that model to confirm that either we're solving it or at least > moving us closer to that strategic endpoint. I think the design doc you guys > have put together is fantastic -- but we really need to also resolve this > very important issue in order to be sure the persistence model and the > roles of kernel and userland here actually make sense. > I am aware of the model you are mentioning, that each link is modeled as an service instance, and I fully agree that it is the way to go. But the Clearview project is not the project to make that model change, and in that respective, we are not making things any better or any worse. Note that the Clearview project uses SMF strictly for the data-link configuration persistence. We choose to use SMF mainly because we'd like to not introduce any more private /etc/*.conf configuration files, and the SMF implementation can be easily leveraged to be an alternate approach to satisfy our needs. Further, the needs for the dladmd daemon is independent from the use of SMF repository. As is discussed in last mail, the dladmd daemon is needed for two reasons: management of the link name, linkid namespace, and data persistence initiated from the kernel. But we could choose to use the private configuration file instead of the SMF repository. I am afraid that there might be something that I don't understand from your mail. I don't see how the change of the SMF model could remove the needs for the daemon, as you seem to imply. Can you please elaborate? Or if you have other suggestion, please also let us know, and we'd like to consider. Thanks - Cathy
