Dan Groves wrote: > I posted a new copy of the link ID management API document to: > > http://www.opensolaris.org/os/project/clearview/uv/link_id_management.pdf
Thanks for putting together this document. Here are some comments and question. * 2.2: I'm wondering if the property groups can be organized somehow. I find that because there are different classes of links each with a different set or properties, that it would be nice to not lump all classes' properties under one group. Is that an option? * 2.2: What is the reason behind having the link's property group name be the name of the link as opposed to the link id? I'm wondering what the pros and cons would be of having this be the other way around, where the id is part of the property group name, and the vanity name is a property. Renaming would then not involve deleting and re-creating the set of properties (or renaming the property group if that's even possible). * 2.2: I assume that "over" is only valid for VLAN links? * 2.2: What are "phy_major" and "phy_minor" used for? * 2.2: You write, "Note that Vanity Naming is not responsible for ensuring all pieces of link con?guration information are persisted in this respository, but we will make e?orts to ensure that later projects can easily move more link con?guration information into SMF." Can you clarify what is meant by that? It's not clear to me. * 2.3: Since linkmgmtd must be keeping track of both the mappings that are in SMF and the mappings for temporary links that aren't in SMF (or are they?), I'm guessing that refresh will do more than read the SMF repository. It'll probably also need to gather the state of datalinks in the kernel on start and refresh. * 3.1.2: Link ids will be referenced all over the system, beyond dladm and libdladm. As such, I'd think we need a more generic type for this. Thanks, -Seb
