> 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?
Yes. An imaginable future researcher who finds a datalink.conf would not be able to tell properties from non-properties unless he also finds the parser. > 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? See below. > 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? In fact, that was my original proposal. The group felt the file format approach was better: http://opensolaris.org/jive/thread.jspa?threadID=57346 I don't really feel strongly about either. Being able to filter out properties requires a centralized registry for "known" non-property names, which requires a higher level of discipline from future maintainers to keep that registry up-to-date. With the format upgrade approach, we draw a line. We only need to know which names are "known" right now. The file conversion logic does not need to know future "known" names. Those names will always be written to datalink.conf in the new format. > What happens on BFUing backwards across the transition? Good question. Perhaps we could put some logic in bfu.sh. I wonder though how file versioning in general is handled in Solaris. For instance, what happens if you create a ZFS with new on-disk format version, then BFU backwards? Do we care about this corner case enough to put extra effort to support it? -Artem
