> 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.
> 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. Just yesterday I thought it was a good idea, but thinking about it further it feels less attractive. I think properties, including private ones, should be defined outside of driver binaries - rather in header files and manuals. Applications should always know the superset of properties that a driver can support and check if a certain property is supported using getprop. If a driver reports some property unknown to an application, it is useless to that application. To make it useful, the driver would have to provide more information, like the range of possible values, etc. Which basically smells like runtime type information, component object models, interface definition languages - "hard drug" kind of stuff not belonging to something as simple as device drivers. In short, I agree that if we're forced to provide relief for ndd compatibility, in doing so we shouldn't mutilate the (still relatively new and clean) GLDv3 interfaces. -Artem
