On (05/25/07 00:20), Garrett D'Amore wrote: > The alternative is for drivers to do _both_ kstats on their own, and > support Nemo mac_stat() entry points. Entirely inelegant. (Btw, the > old GLDv2 suffered this flaw.) This also means that mac_stat
... I think the paragraph above got truncated?.. > The second problem is simply API growth. One can view stats as natural > properties. Many drivers even explicitly export ndd tunables in their > own kstat. Having a separate kind of API for drivers to have to > implement kstats _in addition_ to the API they will already be doing for > Brussels seems wasteful. Brussels should reduce, not increase, code > sizes in device drivers. Another aspect to consider is that, like the ndd props themselves, kstats have become a catch-all for all sorts of information. Some kstats like link speed, would qualify as a property, but there are others like ipackets/opackets are closer to a "statistic" than a "property". Extracting the kstats that would qualify unambiguosly as properties into Brussels would certainly be a good idea. --Sowmini
