On (06/10/08 10:12), Sebastien Roy wrote: > > I don't even think you can guess what output is relevant based on the > > class of a driver. The PHY (or transceiver, or whatever) has to tell you > > what modes it supports. Nemo originally had a 'supported property' mask > > scheme so that h/w drivers could tell the framework what properties were > > actually relevent to them. > > That functionality still exists, but the mask you refer to that was > included in the structure passed into mac_register() (I believe it was > mac_t) has been replaced by a capability scheme (mac_capab_get()). > > This is not necessary, however, since drivers should return ENOTSUP to > property queries that they don't support. This could percolate up to > dladm which could filter out unsupported properties. >
to clarify: I was thinking of something much simpler: dladm/libdladm can query the driver for the default value of adv_10Gfdx_cap (to be added) and filter the output based on the driver's response. --Sowmini
