On Tue, May 29, 2007 at 02:18:36PM -0700, Garrett D'Amore wrote: > 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!)
Indeed. The log message in question may have to vary by media type. For 802.11 link up/down may not be so interesting either, rather, link speed ==/!= 0 would be. > 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.) Why? The transceiver is a physical attribute of the NIC -- if you need one and it's removed then you'll not have link. > 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 log message in question should be consistent across all drivers for the same media type. > The one thing that seems to be universal is the link up/down state. Not so. For wireless link state and speed both depend on signal strength. > Which is probably why that is what is what is record in the MAC layer > rather than the device driver kstats. I don't get this. > 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? Can it change without sysadmin intervention? No. Or did you mean the base station's ID? If so, then, maybe! (It'd be nice to see roaming reflected in the logs, no?) > >>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? I was.
