On (04/01/09 19:36), Peter Memishian wrote:
>
> 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.)
>
> girish.moodalbail responded:
> Sure. The current structure I have defined is not sufficient to support
> multiple ranges, as in 1-6, 10-19, et al. I will extend it to support
> multiple ranges which can be used by properties like CPU.
> >
> Now, I have:
> -------------
>
> typedef struct mac_propval_range {
> uint32_t range_min;
> uint32_t range_max;
> } mac_propval_range_t;
>
>
> I think I need;
> ----------------
>
> 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;
> mac_propval_limit_t range_limit[1];
> } mac_propval_range_t;
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)
Thus I think that while the original proposal would work for solving the one
specific problem of mtu, it does not extend in the way that Meem
is suggesting.
--Sowmini
