Peter Memishian wrote:
>> Sure, but that doesn't mean we have to slice up the problem the same way
>> with a billion little tunables with obscure names, does it? In other
>> words, just because setting this stuff up has currently been modeled as a
>> sea of properties doesn't mean that it should stay that way, or that the
>> way the properties have been decomposed is ideal.
>>
>
> True. But I think it would be even *more* obscure to combine them into
> the MII registers themselves. Normal mortals don't care about "ANAR",
> "ANER", "ANLPAR", "BMSR", and "BMCR".
I certainly wasn't recommending that. I was thinking more about whether
maybe another modeling was in order. For instance, suppose we had a
show-linkcap command -- could we express the configuration more usefully?
As a (possibly lame) example:
LINK DUPLEX CAPABLE ADV PEERADV
bge0 half 10M 10M 10M
bge0 full 10M,100M,1G 10M,100M,1G 10M,100M
... would be equivalent to:
cap_1000fdx yes
cap_1000hdx no
cap_100fdx yes
cap_100hdx no
cap_10fdx yes
cap_10hdx yes
adv_1000fdx_cap yes
adv_1000hdx_cap no
adv_100fdx_cap yes
adv_100hdx_cap no
adv_10fdx_cap yes
adv_10hdx_cap yes
lp_1000fdx_cap no
lp_1000hdx_cap no
lp_100fdx_cap yes
lp_100hdx_cap no
lp_10fdx_cap yes
lp_10hdx_cap yes
Again, I'm not proposing the above (it's based on only a few minutes of
thought and probably riddled with holes), just making it clear what I
meant by alternatives to seas of properties.
Ah. See I'm thinking probably a layer down. In other words, I think
the properties need to exist. How they are presented, is a different
matter entirely.
But, for what it is worth, for a typical 1G device, the list of modes
will be quite a bit larger:
CAPABLE
10M Half, 10M Full, 100M Half, 100M Full, 1G Half, 1G Full
And then you get into *pause* and *master* negotiated bits as well. It
gets really hard to simplify this well.
-- Garrett
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
