On (02/22/08 14:54), Garrett D'Amore wrote: > Looking over this, a few thoughts. > > 1) As you've discovered, some duplication exists with KSTATs. It > strikes me that perhaps a better way to achieve this is to avoid the > whole separate KSTAT mess altogether. By that, I mean Brussels > properties could be obtained from the getprop() interface, and a default > implementation for getstat() can be supplied by Brussels for the benefit > of Brussels drivers. (Having some properties in KSTATs, and some in > Brussels, seems, um, weird.)
yeah, I know. it would be nice if kstats were all implemented via getprops but I'm also getting some pressure to fix CR 6659866, so I might have to defer this. > > 2) DLD_NDD_READ|DLD_NDD_WRITE -- it would be clearer to have a > DLD_NDD_RW macro. ok.. > 3) MAC_KSTAT. Assuming you don't do anything about point 1above, why > not just have DLD_NDD_KSTAT which can be in the same flags field as > DLD_NDD_READ, DLD_NDD_WRITE. It would imply read-only access, of course. sure, they can be coalesced. > Generally, this is a big step in the right direction. Once this (or Yup. I was pleased with being able to rip out the ndd swill from bge and just being able examine the ndd props from mdb by looking at the bge_t structure instead of groveling through the nd_param array :-) >> 2.1 Create a public property that will print out the names of the >> private properties. We could use the DLD_PROP_NDD_LEGACY prop num >> for this property, and it's implementation would look mostly like >> the code in my webrev for ndd_names. >> >> Cons: The output of "ndd -get .. \?" does not fit into the tabular >> format that is used by dladm. To work around this, we could >> make this property inaccessible from dladm/libdladm (i.e., >> only to be used between mac and the driver for legacy ndd >> support) > > It really only belongs, IMO, in the ndd output. One can even question > the value of having it there at all. > > I would not be adverse to an ARC case proposing that the '?' property > simply be removed or not supported by Brussels based drivers. I think > the backlash on this would be either very small or non-existent. The > number of cases of scripts that parse this output is probably quite > small -- I know that QE has some, but they should be converted to use > dladm anyway. I'm afraid that there will be a lot of requests for something like a \? property. The reality is that driver writers will have all sorts of tweaks and backdoors and will want access to the namespace from userland, and if we pull out \? from them, it will only result in other hacks to achieve the same thing. >> 2.2 Require drivers to implement an ioctl that prints out the names >> of private properties. An advantage of such an ioctl would be >> that it can be used by user-apps (including dladm) to get the >> names of private props that the app can then iterate over, to >> get to the value for each property. >> >> Cons: it would be aesthetically better to channel everything >> through GLDv3 interfaces. > > Having a way to enumerate properties does seem generally useful (though > not just for ndd), and thus perhaps a special GLDv3 interface can be > used. Having yet another gldv3 interface seems like a Bad Thing (esp when we are trying to get kstats to align with getprop). > Have you considered the idea of having device drivers "register" their > list of private properties with GLDv3? That was what my first attempt did, and the consensus was that it was too ndd-like. Maybe 2.1 is the way to go? --Sowmini
