Sowmini.Varadhan at Sun.COM writes: > On (08/23/07 11:51), Peter Memishian wrote: > > > > The whole idea of private properties is that they are unstable across > > upgrades. The model you're currently proposing forces us to make a > > What exactly do we mean by "unstable across upgrades"?
Technically, we can change things classed as "private" at any time, without warning, and in any release (including patches). An example of this would be kernel function names. Those can change at any time. Yes, you can write dtrace scripts using fbt that rely on them, and your scripts may break in a patch. We won't provide any compatibility and you may just be out of luck. "Too bad." That's what private means. > Does it > cover the case where I upgrade my machine and find that > the previously private "link_foo" is now a public property? Yes. Anything that was using "link_foo" might break in that (in my opinion, unlikely) scenario. > In any case, if we really feel that private properties *must* be > branded with a prefix, then could we use "_link_" (or even just "_") > as the prefix so that public properties can use the most natural name > appropriate for that property? I'd be in favor of anything that distinguishes them. If you can also follow existing precedent for other parameters, that's great. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
