Nicolas Williams wrote:
> On Tue, May 29, 2007 at 01:37:21PM -0700, Garrett D'Amore wrote:
>
>> Al Hopper wrote:
>>
>>>> Casper.Dik at Sun.COM wrote:
>>>>
>>> You seem to be missing the point - syslogging the interface name with
>>> speed and duplicity is useful in a couple of very practical ways:
>>>
>>> [SNIPPED: three cases not needing speed and duplicity info]
>>>
>>> All these examples are when you're working on the physical hardware.
>>> It's much faster to do this than search the product specific docs -
>>> and you don't have product specific docs if you've built the box and
>>> neglected to label the ethernet ports from a Solaris perspective.
>>>
>> In all of these cases, you _do not_ need to know the link speed/duplex,
>> the "up" and "down" messages that I've proposed will address this need.
>>
>
> Yes, but others have given cases where speed and duplicity information
> is useful.
>
Actually, as I've already indicated, apart from being able to lay blame
on person who changed the settings, I don't understand why they are
useful _in the logs_. I may just be dense.
One problem I have is that assumption that Link speed and duplex are
meaningful all the time works. For non-802.3 links, they aren't. Even
the speed is not necessarily meaningful. (With 802.11 the speed can
change dynamically, very frequently. You don't want to log that for
certain!)
For other devices, the fact that an external or internal transceiver is
likely to be just as relevant as speed and duplex setting. (NICs that
have an external transceiver, for example.) Or media, for nics that
have both copper and fiber ports.)
Again, trying to come up with something _in the logs_ that can be
consistent across all drivers, in a way that doesn't worsen breakage,
seems challenging.
The one thing that seems to be universal is the link up/down state.
Which is probably why that is what is what is record in the MAC layer
rather than the device driver kstats.
Anyway, if folks are dead convinced that we have to have link speed and
duplex for 802.3, I have figured out how to add it without too much
engineering effort or risk. Should we also be logging e.g. the SSID for
802.11 links?
>
>> To re-state:
>>
>> * the link state change will be logged (going from down to up, or
>> vice versa), but the details of speed, duplex, channel, and other link
>> tunables will _not_ be part of the message that I've proposed.
>>
>> Hope that answers this concern.
>>
>
> It doesn't.
>
It doesn't? Why not? Or are you saying it doesn't address the
aforementioned "other cases" that people gave?
-- Garrett
