In order to address the concerns, questions about this, I'm thinking we
can go ahead and log some additional details. It turns out not to be as
painful as I thought, because the reference counting I need to
recursively call into the the device driver to get the stats is
basically already there.
For 802.3 (mac_ether type devices), the logged link-up message could
take the form of:
bge0: link up, 1000Mbps, full duplex
For 802.11 (mac_wifi type devices), its not entirely clear what is most
desirable. We have SSID, security information (WEP/WPA, open/shared-key
auth -- though nobody should ever use shared-key), 802.11 "mode"
(802.11b/802.11g, 802.11a), Infrastructure vs. Adhoc, frequency/channel,
current rate (though that can change at any time). Additionally, even
the notion of associated/authenticated is a bit muddied by 802.11.
What I'd like to do is leave the other non-802.3 messages as just "link
up", with no further details.
In any case, link down messages will still just be "link down".
The main draw back of this approach is that the link notification
messages will be different for ethernet than for any other link layer.
Frankly, I find that kind of distasteful, and I'd rather not encourage
the continued reliance of syslog to obtain details like link speed,
duplex, etc. But I'm also finding it hard to continue to care about it
passionately enough to argue with the few people who still seem to do
care passionately enough.
I guess this then becomes a request for PSARC to provide direction,
which, I'm not sure I can do in a fasttrack.
The options I present to PSARC are:
* shall we take the case as originally proposed?
* shall we amend the case to require link speed and duplex _only_
for ethernet links?
* shall we reject the case altogether? (If the case were to be
derailed, I'd just withdraw it because I don't have nearly enough
interest in this case to run it as a full PSARC case.)
Thanks.
-- Garrett
Al Hopper wrote:
> On Tue, 29 May 2007, Garrett D'Amore wrote:
>
>> Al Hopper wrote:
> ... snip ....
>>> a) you've got a white box with 2 ether interfaces marked "0" and "1"
>>> and you need to identify which is which. Easy - unplug one briefly
>>> and look at the console message.
> .... snip ...
>> 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.
>>
>> 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.
>
> Every time I (personally) see the link up/down message, I *always* do
> a mental "sanity check" to determine if the speed/duplicity settings
> were "as expected". In our local environment that would almost always
> be "1000Mbps full duplex" for an interface that is gigabit capable.
>
> However, in a large client environment I am familiar with, it should
> always be 100Mbps/full duplex, because they have "hard coded" every
> bloody port in the entire datacenter[0]. Or at least, attempted
> to[1]. So the speed/duplicity is always sanity checked - and I know
> the sys admins I work closely with _always_ check it also.
>
>> Hope that answers this concern.
>
> I think the current info is very useful and should be retained, if at
> all possible.
>
> On a side note, as a developer, when I have my head in some code, I
> generally look at what is logged at the "info" level and see if there
> is some other data that is "close by" that might be useful and append
> it to the message. In this case, when I say "close by", I mean in a
> local data structure, or function arg, that is easy and inexpensively
> (from a system resource perspective) added.
>
> [0] your typical design by committee where the techies on the
> committee are out-numbered 10 to 1 by 100% Buzzword Compliant
> Management Types (BCMT).
>
> [1] Until they swap out a switch supervisor board, or upgrade the
> switch code - or some "new guy" comes along and "fixes" the current
> switch configs. Or they move the wires over to a new switch (during a
> maintenance window that we never received notification of).
>
> Regards,
>
> Al Hopper Logical Approach Inc, Plano, TX. al at logical-approach.com
> Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT
> OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007
> http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/
