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
