> 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?
No objections here. One thing that I've wrestled with in the past (and never satisfactorily resolved) was with how to handle values that are generally supported but not supported based on the current configuration (e.g., because of the underlying driver, type of link, or other datalink configuration). In a GUI, these would be the things that we'd "gray out" to indicate to the administrator "if you *could* set this, you'd do it here, but it's not supported with your present configuration". -- meem
