rpc.kstatd: Remote Kstat Access Service [PSARC/2008/502 FastTrack timeout 08/13/2008]
James Carlson
james.d.carlson at sun.com
Thu Aug 7 13:39:30 PDT 2008
Nicolas Williams writes:
> On Thu, Aug 07, 2008 at 03:36:07PM -0400, James Carlson wrote:
> > Indeed. And I doubt this case really makes it as obvious enough to be
> > a fast-track.
>
> We can certainly go for a full case if that's desired (I just can't own
> such a case, being only a licensee).
I'm not pulling on that derail lever.
> > I think that's already the case. Unless the users of this interface
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You don't sound convinced of the obviousness of the case either way :)
Terminology overload: the word "case" above wasn't referring to this
project.
Instead, the statement could be rewritten equivalently as:
"I think that's already true."
In other words, what Garrett was saying (that other projects have no
obligation to this one) is I think already true by virtue of the lack
of interface stability.
> It might be nice to have kstats modules export a version kstat so that
> consumers can more trivially decide if they can use a remote module's
> kstats. And/or it may be nice to have a rule that says you must rename
> a kstat when changing its semantics in incompatible ways. But that
> would be so even without this case.
That is a problem for a different project.
The project you're suggesting is "here's how I export statistics from
my module in a way that allows others to cope with change." How
that's done may well vary by subsystem, but a version number could
possibly be one part of the solution, along with an elevated stability
level.
I think it's way too early to be recommending some kind of solution to
that problem; we don't have a project suggesting such a change at
hand, and we can't just invent one. In addition, just slapping on
version numbers to handle unplanned-for change rarely actually works.
It's a bigger problem than just numbering.
--
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
More information about the opensolaris-arc
mailing list