Sowmini.Varadhan at Sun.COM 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 > > Still catching up on this thread, so please bear with me if > I'm bringing up items already discussed: > > thanks for putting together this doc.. it's a helpful encapsulation > for other projects.. > > Section 2.2: > - What exactly do you mean by "Vanity Naming is not responsible > for ensuring all pieces of link configuration information are persistent.." > Currently /sbin/dladm ensures persistency of a "set-linkprop" information. > How will this happen in the smf model? Will that be done as part of the > svc [re]start during boot? >
All we're going to store in SMF at this point is data required to create a link. I plan to provide a way that others can store more information in SMF. I see I used a poor choice of words. I'll reword the section. > - is fixed_mac_addr the same as "local_mac_addr?" today? If yes, are there > plans to keep the 2 in sync (local_mac_addr? can be set via obp :-() > It's used for aggregations to specify if the unicast address for the aggregation is fixed or not. So, no, it's not the same. > - As Seb pointed out, it would be good to have the property groups > organized, instead of a flat classification. As far as implementation > goes, perhaps some sort of internal "union" like definition would > make sense. > > - follow-on question to the above: what will happen if a vanity named > link (say "net1") built on top of an aggregation is switched over to > bge0? i.e., some properties may be meaningfully transferred over to > the new model, but some would be invalid. > > - Cathy made a reference to "name-value" pairs (which is how /sbin/dladm > and the /etc/dladm/*.conf files today deal with input, with both name > and value are handled as strings) but Dan says > > "I disagree that the fields we store are implementation details. How we > store things is an implementation detail, but what we store and where we > store are not, in my mind." > > Is there going to be some formal registration for each new property > with strong-typing in the new proposal? > I think I can answer all three of these at one shot. Cathy and I were talking privately, and what I've got in the document doesn't correctly describe what I'm try to do. I'm writing an API to store link data in some type of storage, in this case SMF. Everything will be stored as a name-value pair, there's not going to be any strong typing. The user of the API tells the API what it wants stored. In your example of net1 being switched from an aggregation to bge0, I would expect the API caller to do the hard work of rearranging the link properties (which could be as easy as deleting the old net1 and creating a new net1). The different fields I listed are just a list of what we intend to put in as part of the Vanity Naming work. It's there as a convenience. It's subject to change (I expect NWAM will add to the list). This section I need to rework. I don't know if I will have a new version ready today. > Section 3.1.4: > - need to add some datatype for array, since dladm allows these to > be set in the repository. > Array of what? String data? integer data? Something else? > General: > > - I, at least, got somewhat confused between references to "Link Configuration > Data" and "properties". It would be helpful to clarify the relation > between the two, in a "Definitions" section. > I seem to mixed up SMF objects with other things. I'll go through the document and clean it up. > - a related question: I see that the difference between "property group > name" and "link name" was discussed in this thread. Could you please > define what the "property group name" is? > SMF property groups have a name, and I decided to name the property groups we create for vanity naming after the link name. thanks for the comments, Dan
