Dan Groves wrote: > Sebastien Roy wrote: >> * 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.
I'm not sure if it's really necessary. I was just curious if perhaps the concept of link class could somehow be represented in SMF in some inherent way. > 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. What you have is fine. >> * 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. I don't have a strong argument for changing the design that you have, so I wouldn't push you to rethink anything. I was more curious if there had been much thinking either way to lead us to one design, and if one method was particularly superior over the other for some reason. >> * 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. Okay. > >> * 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. My comment was geared toward addressing what linkmgmtd does when it starts up and there are already links configured in the kernel, such as what would happen when the daemon crashes and is restarted by SMF. In that case, I'm guessing it needs to get a set of link id's from the kernel, right? >> * 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? Meem's suggestion of datalink_id_t seems okay to me. Thanks, -Seb
