Michael Shapiro wrote: >> > That issue is trivially solved by using smf instances as I suggested -- >> > if every datalink has its own instance (think "network/datalink:foo0") >> > then by definition of the single FMRI namespace no one can create >> > another instance "foo0" and you don't need to write any code to >> > enforce that because smf enforces it by design. >> >> [ I fear I've misunderstood what you're suggesting. ] >> >> I don't see how that solves the problem. Suppose a new network device is >> attached and the driver's attach() routine is called, which then calls >> mac_register() or whatever to drive the creation of the link. As part of >> that, a new link is going to be instantiated, which will need a new unique >> link identifier. How will the kernel know what link identifier it can use >> for that without knowing what link identifiers are associated with >> temporarily deleted links? Of course, if we track all link identifiers >> (even deleted ones) in the kernel, then we can do that, but then we're >> back to tracking state that is not otherwise relevant :-/ >> >> Also, another core piece of the current design is that the bindings of >> link identifiers to link names are persistent across reboots. So even if >> we tracked them in the kernel, we'd need to commit them to stable storage >> across a reboot. >> > > Actually I'm trying to understand what set of cases you're trying to solve. > This may be easier to discuss in person or over the phone, but let's step > back to this top-level question: > > In the diagrams you have a mapping from link-id to vanity name in the daemon. > I see clearly discussed in the doc that when a new interface attaches it gets > the default name, and no link-id.
When a new device attaches, it will upcall to the daemon with the *device instance name*, so that it can lookup its link name and linkid, and create the kernel data-link. Note that the kernel data-link is only created *after* the upcall is successfully done. > Then we upcall the daemon. It assigns a > link-id, pokes the kernel. Then I can reassign the name, which can poke > the kernel to change the name, and I can generally operate on the identifier. > > 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. Thanks - Cathy > Or is there something else going on? Explain this part better and then > I can ask some follow-up questions. > > -Mike >
