Peter Memishian wrote:
> > On (06/22/07 18:58), Peter Memishian wrote:
> > > But link_speed isn't listed in ieee802.3(5) -- so does this mean we'll
> use
> > > "speed"? More generally, I'm not convinced that reusing those names is
> > > the right choice (Do we really want to have a "link_up" property? Or do
> >
> > right, so the decision (if you follow all the emails that were
> > subsequently exchanged) was to just follow the MII definitions and use
> > "adv_1000fdx_cap" etc.
>
> I'm not sure I follow, but I don't want to sweat the names too much at
> this point.
>
> > > we really need to have the output of show-linkprop to be knee-deep in
> > > obscure link negotiation options like "lp_cap_1000hdx"?)
> >
> > I personally agree, and these values are printed via kstat if needed,
> > but as Raymond pointed out, users can now use one command (ndd) to find
> > out both the advertised and link-partner's capability. If we are going
> > to deprecate ndd, we should have a tool that provides both in one shot..
>
> 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". (And that's just for 100Mbps
links. For Gb, 10Gb, and pause/asmpause, its even more stuff.) They
just want to know what the peer supports, what the local host supports,
and what the local host is requesting. If you can come up with a better
way to compose the information without loss of information, then please
make a suggestion.
-- Garrett
