Hello, Sebastien Roy wrote: > 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? >
I could change the documentation to show some organization. We could write code that only stores certain properties for certain types of links. That reduce some flexibility, but could give us better error handling. Right now I wasn't planning on writing any code in linkmgmtd to impose any structure on what properties we store for each link, i.e. if an administrator had configured a property for a link linkmgmtd will store it, regardless if it makes sense for the class of link. > * 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). > Having the property group's name be the link name makes the rename case more difficult. I decided to go this way in case sometime in the future someone will need to access the link's SMF properties via svcprop. We really don't want that to happen, administrators should only use dladm. But I don't know what will happen or how things will change. You're not the only one to bring this issue up. I wonder if I should rethink this approach. > * 2.2: I assume that "over" is only valid for VLAN links? > Yes. > * 2.2: What are "phy_major" and "phy_minor" used for? > I see Cathy already answered that. > * 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. > Basically, I'd like whatever we do here to make it easy for NWAM or other projects to add more things to the SMF repository, or even change how we store things in SMF. That sentence in section 2.2 might be more clear if the document was finished. I plan to add a section about the internals of the API, describing the door calls and how we manage the link ID to name mapping in linkmgmtd. I hope to start work on that section soon. > * 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. > We weren't planning to put the temporary links in SMF. From my reading of the SMF materials, it looked like having temporary property groups was follow on work and not available now (If I'm wrong, please correct me). All the mappings, temporary and persistent, should always be in linkmgmtd. If the kernel needs to temporarily create a link, it should get a link ID from linkmgmtd, so I don't think there should be anything in the kernel that's not already in linkmgmtd. > * 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. > Originally I had linkid_t, and I recall someone (I don't remember who) commenting that this type needed a prefix to prevent collisions with the use of linkid_t in other areas of the code. I picked dladm_linkid_t because it seemed to make the most sense. Are you suggesting I should have a different prefix, say "datalink_linkid_t"? Or something else? thanks for the comments, Dan > Thanks, > -Seb
