> > Since Dan is on vacation, and since I think I'm responsible for it going > in this direction, let me provide some more background. > > > Thanks for the updated notes (I also looked at the design doc). Now > > that I look at the reasoning, I'm really thinking that you should not > > put that functionality in a daemon and just put it into the kernel. > > Obviously I'm not an expert on your source code, but fundamentally if I > > look at Figure 4 pg 33 of your design doc it looks to me like the link > > mapping being maintained in user space would be easy to keep in your > > kernel data-link hash table. > > One key issue is that there are links that are not part of the running > system. For instance, someone may create a persistent link and then > delete it temporarily. Once it's been temporarily deleted, it's no longer > relevant to the kernel, but because of the expected userland behavior, we > still need to prevent another link from using its name or using its link > identifier. While it would be possible to have the kernel continue to > track temporarily deleted links, I was very uneasy with the idea of adding > machinery to the kernel to track things that are only necessary to enforce > userland policy.
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. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
