Peter Tribble wrote:
> Actually, I had another thought. Why do the rule statistics have to use ilb
> as the module? Why not use 'ilb_rule'? That completely avoids any possibility
> of naming conflicts, and also has the advantage that you can safely number
> rules from 0.
Right now, the design is that every rule has a name. And
no two rules can have the same name. The rule name is
assigned by the user who creates a rule. So if we ignore
the meaning of instance, we can easily use instance 0 for
the global ilb stats and then use other instance number for
rules. Then there will be no name conflict with "global."
> That's exactly what I'm suggesting. As you say, instance number isn't
> really meaningful, so that I don't feel too guilty about appropriating it.
>
> One other possibility would be
>
> ilb:0:rule77
>
> but that's just horrible - you have to go parsing the names into their
> constituent parts.
The name is assigned by the user. So it is up to the
user how to call it. And it is easy to just use
kstat -m ilb -c rulestat -n <rule name>
to retrieve the stats of a rule with name <rule name>.
> I would normally want to be able to get at all the rule statistics
> easily, and would hen simply display the lot or do additional
> processing based on content. So I would want the kstat names
> and classes to be fixed strings known in advance.
But without using a different names, it is not easy to
retrieve stats for a specific rule. Using your suggestion,
either stats from all rules will be retrieved, or somehow
the user needs to know the instance number. But AFAICT,
the instance number is generated on the fly by the kernel.
--
K. Poon.
kacheong.poon at sun.com
