> > Here's what I'm missing (i.e. not seeing in 6.2.8) -- what happens when the > > system boots? Do all extant h/w interfaces start out with no link-id and > > the default name, and then get assigned their persisted name and id as > > part of the dladmd startup? i.e. is the mapping that is referred to as > > [ link-id, link name ] in fact [ link-id, link name, default link name ] ? > > > The daemon is started early enough that network/physical and device/local > service all depend on it. So that it make sure when the device attaches, it > can successfully lookup its link name using the upcall. > > As Meem said, we decide to use a daemon to manage the <link name, linkid> > mapping because this mapping is needed for both active links (links are > available and have associated data structure in the kernel) and persistent > links (links are not available but are expected to be available in next > reboot). Some links are both active and persistent and those active and > persistent links share the same link name name space. So that we'd like to > have a single place to manage this mapping. At the same time, we also feel > that kernel should not manage things that are not related to the kernel > state (i.e., those peristent-only links). Therefore, we choose to use a > daemon. > > Using a daemon also helped to persist information for physical links. > Because the creation of a physical link is initiated from the kernel (from > the device's attach routine -> mac_register() -> dls_create()), and persist > information from the kernel directly is not easy. The upcall from the kernel > to the daemon makes it easy to persist the information for this physical > link if the upcall finds this is a *new* link. > > To explain this, I am giving an extreme example as below. Assume we have a > new bge2 device, the code path would be: > > bge_attach()->mac_register()->dls_create() > > dls_create() will upcall to the daemon to lookup its <linkname, linkid> > mapping using the device name bge2. The daemon might find this is a new > link, but the link name bge2 has already be used by another link (this is an > extreme case, but it is possible), so the daemon assign the <"net0", 12345> > <linkname, linkid> mapping to this bge2 device, and persist this mapping. > Therefore, this device will always be associated to the link name net0 even > across reboot.
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? 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. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
