On (01/31/08 14:21), Sebastien Roy wrote: > > A related question, though one that can be addressed outside the scope of > this particular code-review, is what is the harm in letting libdladm send > down a request for the state, and having the driver answer, "I don't know > what you're talking about", instead of encoding support for various types > in libdladm itself?
That's a good point. That would make status a property applying to all media types, and we should probably also extend link_state_t to take care of the various wifi states that Garrett mentioned. Another related issue that comes to mind is that, for printing DEFAULT and POSSIBLE values, we currently have a strong bias in dladm for using constant val_desc_t structures. (wifi drivers have some exceptions for POSSIBLE, via the pd_getmod callback, but the code everywhere expects constant DEFAULT values). So the "default" can vary based on the link type- e.g., for mtu where the default for ethernet != default for iptunnel. So one enhancement would be to have a "DEFAULT" flag passed down with the set/getprop, and pass these flags all the way to the driver. In the case of a setprop, the driver would then reset itself to the defaults, in the case of getprop, it would return the default. Similarly we could have a MODIFIABLE flag (invalid with a setprop, can get POSSIBLE list with getprop) Comments? --Sowmini
