Cathy Zhou wrote:
> Darren Reed wrote:
>
>> Cathy,
>>
>> In the "kstats after vanity naming" thread from November last year,
>> there was
>> some discussion about how vanity naming would impact kstats...
>>
>> I have a concern or two...
>>
>> Today, if I'm using kstat(3kstat), i can derive the instance number
>> and the
>> name from the interface name. So if someone passes "bge2" into my
>> program,
>> I know that I need to call kstat_lookup like this:
>> kstat_lookup(kc, "bge", 2, "bge2")
>>
>> In the new world of vanity naming, how does one call kstat_lookup()?
>> Specifically, how do i know if I should be calling it like this:
>> kstat_lookup(kc, "link", 0, "net0")
>>
> I would think that one should only call kstat_lookup(kc, NULL, NULL,
> <linkname>, 0).
That's not a correct use of kstat_lookup(), I presume you meant:
kstat_lookup(kc, NULL, -1, <linkname>)
This is an imprecise way of calling kstat_lookup().
> Please be noted that the kstat lookup does not usually work as we
> expect even today, for example, one would hope to successfully lookup
> the link_state kstat for VLANs the same way as for normal links, but
> it does not usually work (see 6512267).
Which is a bug in the provision of some kstat information,
but not a bug in the way kstat is used...
> I think one should always look up the kstat using the kstat name (not
> the module name and instance number) even today.
But that's not how people do it today,
and nor is it a very precise way of using kstat.
> ...
>
>> What will happen to old applications that get a vanity name network
>> interface given to them, such as "net0", but try to call kstat like
>> this:
>> kstat_lookup(kc, "net", 0, "net0")
>>
>> ...because the only way to derive the instance# is from the name and
>> they expect the name to match the old naming convention....
>> Will old programs fail to work with kstats after UV?
>>
> Note that vanity naming is not turned on by default, the old
> applications should just work if there is no vanity naming on the
> system (as we kept the old kstat syntax, also, be noted the old
> application might not work as it expects as 6512267 suggests). In the
> future, I'd hope that applications can be changed based on the new syntax.
Vanity naming is there, waiting to be used, when the system is
installed. To the best of my knowledge, there's no special magic
required apart from using dladm to rename a link, at which point
I doubt there is a message saying "oops, don't use your new link
name with kstat programs because they may not work."
6512267 describes a bug, it doesn't describe a problem with kstat.
Let me illustrate the problem.
Today if I'm given a network interface name of "bge0", the most
correct way to ask kstat about it is to use a call like this:
kstat_lookup(kc, "bge", 0, "bge0")
...as it removes any ambiguity of what it is I am looking for.
Software that does this works today as it has in the past,
*without any changes*.
Vanity naming changes this because it allows the link name to
use any name, possibly intruding into the namespace of other
devices on the system (so far as kstat is concerned.) So if I
renamed my network interface to a name that is found in kstat
(and cpu0 is not one of those), such as cmdk0, if my program
then does:
kstat_lookup(kc, NULL, -1, "cmdk0")
it may fail* when it does kstat_data_lookup().
(* - I don't know what it's going to return yet because I haven't
been able to test it on a clearview box.)
Now why would someone rename their link to "cmdk0"?
Who knows. So you might argue that there's a certain
amount of "pilot error" here but there is also the question
of whether or not UV should allow pilot errors like that.
Similarly, it would fail the same as if I called it with:
kstat_lookup(kc, "cmdk", 0, "cmdk0")
I don't see how you can divine whether or not the caller is
asking for cmdk0 disk stats or link stats.
Now if I call kstat like this:
kstat_lookup(kc, "link", -1, "cmdk0")
then I get access to the newer style of kstat information for
the NIC and not the disk statistics. The catch here is that
nobody's application has been written that way, hence there
are changes required for netstat, snmp, rpcsvc, etc. These
should be something of the canary in the coalmine. For
people who want to deliver source code that works on both
Solaris 10+clearview and Solaris(everything else), code will
need to look something like this:
#ifdef SOLARIS_CLEARVIEW
kc = kstat_open();
ksp = kstat_lookup(kc, "link", -1, ifname);
kstat_read(kc, ksp, NULL);
kstat_data_lookup(ksp, "newname");
#else
kc = kstat_open();
ksp = kstat_lookup(kc, module, instance, ifname);
kstat_read(kc, ksp, NULL);
kstat_data_lookup(ksp, "oldname");
#endif
Or this if the kstat data name is the same:
kc = kstat_open();
if ((ksp = kstat_lookup(kc, "link", -1, ifname)) == NULL)
ksp = kstat_lookup(kc, module, instance, ifname);
The only caveat here is that it isn't clear whether or not the
names used within kstat are stable and thus whether or not
this your escape hatch. I'm concerned that there's a major
architectural problem here (with respect to names and using
kstat) that people won't find out about until they get bitten by it.
In November of last year, the following was said:
Cathy Zhou wrote On 11/08/06 20:01,:
> Peter Memishian wrote:
> > Regardless, the semantics of the module, instance, and name fields are
> > unclear to me. For instance, bge0 also has:
> >
> > module: bge instance: 0
> > name: parameters class: net
> > 1000fdx_cap 1
> > 1000hdx_cap 1
> > [ ... ]
> >
> > ... but given the namespace issue, I don't know how we could follow
> this
> > same convention. Perhaps we have more research to do here?
> >
> You mean a research of how people usually use them?
I never saw an answer to that question.
What was the outcome here?
Did you do that research?
If you did, where did you look in order to do it?
Darren
