[driver-discuss] Re: [brussels-dev] dladm show-linkprop enhancements

Peter Memishian peter.memishian at Sun.COM
Mon Jun 25 20:18:38 PDT 2007


 >> 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.

-- 
meem



More information about the driver-discuss mailing list