Sebastien Roy wrote: > 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. >
I see. >> 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. > OK, then I will leave the code and design document as-is. >>> * 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. > OK. Unless we discover some problems when we test renames, I'm going to leave this as-is. > >> >>> * 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? > I see you what say. Yes, this does indicate we'll need some way to communicate this data between the kernel and linkmgmtd. We don't have that currently, and will need to add it. I'll some text about this communication in section two, and then in the later section on the internals I'll go into more detail. >>> * 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. > OK, I'll update the document to change dladm_linkid_t to datalink_id_t. thanks for the comments, Dan
