Artem Kachitchkine writes: > > 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.
I have trouble imagining that person. > > 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 Unless I misread that thread, it looks like the prefixing was a proposal from Cathy and you, and not quite a "group" decision. I'm not trying to pick on it; I'm just trying to understand the rationale, because changing the file syntax obviously has costs to it, and I'm not sure I understand the lasting benefit. Most of that discussion thread seems to be about reserved characters. I agree with meem that if we have reserved characters in the value portion of the string, and we're not escaping them now, then that's a clear bug. I think that's a separate issue from the prefixing one. I'm not so sure I agree on the property name portion of the special character discussion. There's no need for "users" to pick new property names; that's a system design (and for private properties a driver design) issue. At most, we'd need to make sure that any non-linkprop names that we create are names that we'll just never _want_ to use as a linkprop. That alone solves the problem. > 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. I don't understand this concern. The properties are just plain meaningless without that "centralized registry." In other words, if there's no software that reads the property and does something based on it, then who *cares* what we store in the file? It makes no difference in the operation of the system. Any software that can read out properties by name is a de-facto "registry" of known names. Since that software must exist in order to have a meaningful use of this file, the feared registry must exist. We can't really avoid it. At most, it's just being called by a different name. > 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. I'm still not getting how this helps. Let's jump into the future for a moment in which the new prefixing scheme has been established. You have a datalink.conf file on your system. It has some per-link records, each with a set of keyword-value pairs. Let's suppose that this new format is "helping." There are known keywords without the prefix ("class") that are not link properties. There are also keywords with a "linkprop:" prefix that are link properties. However, are there any keywords without the prefix that are unknown? How can that possibly happen? Where did they come from? They have to be infrastructure items (as they're not identifiably linkprop items), which means they have to have been installed by system software. I don't understand that case, and thus I don't understand what's being fixed here. It seems much easier to me to say that all unrecognized keywords are (by definition) considered to be link properties, and eliminate that class of items that are neither one thing nor another. I suspect that the *real* issue is in the construction of an iterator for linkprops and *not* in any clear benefits for the file format. The real benefit is in not having to gather together all of those known keywords in order to eliminate them for use in a linkprop iterator. If so, then the discussion about "future researchers" is really beside the point. However, even at that, I think there's some benefit to be had by centralizing the matching of known special-case (non-linkprop) keywords, so that this isn't just strewn about the source base. You could centralize it so there'd be a single "get non-linkprop value" function that takes an enumerated value, and that uses a list that can be used to exclude entries as linkprops. > > 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? We do. The on-disk zfs (and zpool) version numbers don't change until the administrator explicitly asks to upgrade them, and once you do that, you can't go back to any older version. In general, there's limited support for BFUing backwards, so that lab machines don't have to be installed over and over again from scratch. If you have to have a flag day to fix some important problem here, then that's fine, but if you can avoid it, you'll make more people happy. -- 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
