sowmini.varadhan at sun.com wrote:
> 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.
>
I don't think that's good enough, though.
I'd rather have a way for dladm/libdladm to know that a property is not
supported by a driver (or even a particular bit of hardware). This
might mean reporting ENOTSUP for those properties. In some cases this
might also mean that we should add new properties for capability bits.
(The current drivers seem to use the "default" flag to this purpose, but
its not quite right.)
Think MAC_PROP_CAN_ADV_100T4_CAP or somesuch.
-- Garrett
> --Sowmini
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
>
