> Hi, > > I've posted a new copy of the link management API document at: > > http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf > > Changes include: > > - brief explanation of why we use a daemon > - change service name from network/dladmd to network/link-management > - change dladm_class_t to datalink_class_t, and change the names of the > type's values. > > thanks for the comments, > Dan
Dan, 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. The kernel should own all of the abstractions here, with SMF simply functioning as the means of taking the administrator's intent (a set of instances and properties) and plumbing up or tearing down the kernel state. I would model this as each datalink being a separate instance and its start method simply creating that abstraction -- in the event that there is a duplicate in the one true arbiter of state (the kernel), that service fails and enters the maintenance state. In other words, every instance simply has a startup method which calls dladm to configure the state in the kernel. If you have a daemon purely for this name/id relationship I think you are heading down a path where you're spreading the state of a single set of abstractions between kernel and userland which is almost always a bad idea. Here's one example consequence: one will not be able to use DTrace to capture the link names using the forthcoming net provider or other providers -- because wherever I'm instrumenting the kernel I can't then jump from that context into some arbitrary data structure inside of dladmd. I'd be happy to discuss this further offline or in a meeting if that would be helpful. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/
