> > > 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. 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 ] ? Or is there something else going on? Explain this part better and then I can ask some follow-up questions. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
