On 04/02/09 09:37, Sowmini.Varadhan at Sun.COM wrote:
> On (04/02/09 09:18), James Carlson wrote:
>> Sowmini.Varadhan at Sun.COM writes:
>>> But that is not enough.
>>>
>>> what if the property's POSSIBLE values are strings, or if the
>>> ranges have very differnt units (e.g., speeds can be anything between
>>> 10 Mbps to 10Gbps, with 802.11b drivers support 1, 2, 5.5 and 11 Mbps)
>> If they're strings, then I don't think they're ranges, but are rather
>> enumerated values.
>
> correct, but Meem was proposing:
>
>> The notion of having a range/collection of values for POSSIBLE is generic
>> and thus seems like something that should be thus extended into the
>> linkprop framework itself rather than one-offed through a parallel set of
>> mac properties as has been done. For instance, I'd expect this would also
>> apply to the "cpus" link property. (Further, there is a CR for covering
>> inputting ranges as well (6822164), which doesn't apply for MTU but
>> certainly applies in the general case.)
>
> so a full-fledged solution for extracting "POSSIBLE" for a general property
> should be able to handle an enumerated return value, right?
Well then I will have a 'void **';
-------------
typedef struct mac_propval_limit {
uint32_t range_min;
uint32_t range_max;
} mac_propval_limit_t;
typedef struct mac_propval_range {
uint32_t range_num;
void **range_lim;
} mac_propval_range_t;
------------
for MTU and CPU values you could typecast it to "mac_propval_limit_t".
thanks
~Girish
