>> 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>)
>
That's correct. Sorry for the typo.
> This is an imprecise way of calling kstat_lookup().
>
Sadly, it is used very often, actually, in 2 out of 3 examples you pointed out.
cmd/cmd-inet/usr.sbin/in.routed/if.c
cmd/rpcsvc/rstat_proc.c
But I agree with you, I think the way you proposed below makes more sense.
>
>> 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...
>
... which points out that sometimes we provide kstats not even using in the
form of <module>/<instance>/<device name> (in this case, it is
<module>/<instance>/"mii"), and the application is hard to predict that. So
that some application work around it by kstat_lookup(kc, <module>,
<instance>, NULL), which also has ambiguity.
>> 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."
>
> 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")
>
Note that this would still work (if vanity naming is not used), as we kept
the "legacy" kstats.
The things won't work is that if you renamed bge0 to net0, and tries to
lookup its kstat using kstat_lookup(kc, "net", 0, "net0").
> kc = kstat_open();
> if ((ksp = kstat_lookup(kc, "link", -1, ifname)) == NULL)
> ksp = kstat_lookup(kc, module, instance, ifname);
>
I think this would be the precise way to lookup a kstat after UV.
> 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.
>
Sorry. I don't think I understand. Can you clarify what architectural
problem you meant?
>
> In November of last year, the following was said:
>
>>> 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?
>>>
>
> 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?
>
Right. That is *the* problem. The user is not able to predict the kstat name
as and lookup in the precise way as you proposed. I looked at the code in
NV, and googled on the Internet, and found in order to lookup the right
kstat, there is a lot of workaround. People tends to lookup a kstat using:
a. module, instance only, and hope for the best:
kstat_lookup(kc, <module>, <instance>, NULL);
b. a while loop, until its find one:
for (ksp = kc->kc_chain; ksp != NULL; ksp = ksp->ks_next) {
if (strcmp(ksp->ks_module, module) == 0 &&
ksp->ks_instance == instance) {
...
}
}
My take to this problem is that we provide most commonly used kstats using
its link name, (similar problem described in 6512267). With that, plus your
proposed way to lookup a kstat, it should then work.
Anyway, I am copying this mail to the network-discuss alias, and hopefully
we can get more opinions there.
Thanks for your comments.
- Cathy
_______________________________________________
networking-discuss mailing list
[email protected]
