Re: Bonded NIC's did not come up at boot?
Camaleón put forth on 11/24/2010 4:58 AM:
> On Wed, 24 Nov 2010 04:09:53 -0600, Stan Hoeppner wrote:
>
>> Camaleón put forth on 11/24/2010 1:21 AM:
>
> (...)
>
>>> No need to be "picky", everything can be improved. Error management and
>>> user interaction are also an important part of programming design and
>>> development.
>>
>> I think you're assuming that since mii-tool doesn't bomb out when
>> specifying a virtual NIC, but actually shows some data on link speed and
>> duplex, that it _should_ give an error for those instead. If it bombed
>> out instead, what would you be saying? You'd be saying what I have:
>> It's not designed to work with virtual NICs.
>>
>> Write the developers and ask them to make the next version bomb with
>> virtual NICs, which is what it should do.
>
> Why bombing?
>
> A warning message is far more elegant and useful since makes the user to
> question himself if he is using the right tool for the job.
Oh, so you want a product safety warning, like that found on a can of
spray paint saying "POISON: Do not inhale contents"?
~# ethtool lo
Settings for lo:
Link detected: yes
~# mii-tool lo
SIOCGMIIPHY on 'lo' failed: Operation not supported
There is no link for ethtool to detect, so it's output is BS. mii-tool
at least gave a reasonably clear error in this case. However...
Pointing mii-tool or ethtool at a virtual NIC is just as stupid as
pointing it at the loopback device as both are, once again, VIRTUAL
devices, and have no physical parameters such as link speed or duplex,
because they don't have a PHY. These tools are designed to query a PHY
for link speed and duplex.
Do you understand my point now? Only ignorant people would point
mii-tool or ethtool at a _virtual_ NIC, just as only ignorant people
would point these tools at the loopback device. Do you understand my
point? Did I really need to be this blunt?
--
Stan
Reply to: