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