Artem Kachitchkine writes: > The big assumption is that the set of public properties is limited and > well-known. This assumption is reflected in datalink.conf format, e.g.: > > name=string,bge0;class=int,1;media=int,4;mtu=int,9000;_foo=string,bar; > > Properties (mtu, _foo) are not self-identifying and indistinguishable > from non-property attributes. The big assumption breaks for private > properties, which are not well-known and potentially unlimited.
OK; that's an argument against looping over the "known" types and in favor of looping over the elements stored in the file, but how is that either a problem of "self-identifying" or "distinguishing?" I *think* what you're saying is that the file doesn't distinguish between data stored in the file that's related to the support of "linkprop" variables and those items that are not represented via "linkprop" but are instead are more internal parts of the implementation. Is that the issue? If so, then perhaps my comment is a minor issue, but have you considered making the _other_ things more distinct? The "linkprops" values seem to be the dumping ground for all common variables associated with links, but the other items seem a lot more specific in purpose and less likely to grow much over time. Why make the common case more verbose? > 4. Transition plan: enhance dlmgmtd to detect old datalink.conf > format and upgrade to new format. Thus, format conversion would > occur automatically upon first boot after upgrade. Same could be > achieved using class action script, but with OpenSolaris switching > from SVR packaging to IPS, our approach is more future proof. What happens on BFUing backwards across the transition? If dlmgmtd can always detect the "old" format, then why bother changing formats? Can't you just detect on the fly and segregate values into two groups when you read the file? You'd have a fixed list of "known" non-linkprop names, and anything else must obviously be a linkprop. Wouldn't that be simpler ... ? What am I missing? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
