James Carlson wrote: > That's exactly the point. Nobody has promised to provide anything > other than human (English only!) readable messages here. The contents > of the messages are no kind of programming interface. They're not > documented anywhere.
A quick search of docs.sun.com found several places where we document these kinds of messages. I'm sure that there are others on bigadmin as well... http://docs.sun.com/app/docs/doc/806-1075/6jacsnimr?a=view > ======================= > le0: No carrier-- cable disconnected or hub link test disabled? > Cause > > Stand-alone machines with no Ethernet port connection get this > error when the system tries to access the network. If the > Ethernet cable is connected, this message could result from > a mismatch between the machine's NVRAM settings and the > Ethernet hub settings. > Action > If this message is continuous, try to save any work to a > local disk. > When a machine is configured as a networked system, it must > be plugged into the Ethernet with a twisted pair J45 connector. > If the Ethernet cable is plugged in, find out whether or not > the Ethernet hub does a link integrity test. Then become > superuser to check and possibly set the machine's NVRAM. If > the hub's link integrity test is disabled, set this variable > to false. > # eeprom | grep tpe > tpe-link-test?=true > # eeprom 'tpe-link-test?=false' > The default setting is true. If for some reason tpe-link-test? > was set to false, and the hub's link integrity test is enabled, > reset this variable to true. > ======================= > le0: No carrier-- transceiver cable problem? > Cause > Stand-alone machines with no Ethernet port connection get > this error when the system tries to access the network. > Action > If this message is continuous, try to save any work to a > local disk. > When a machine is configured as a networked system, it must > be plugged into the Ethernet with either a twisted pair J45 > connector or thicknet 10Base-T connector (depending on the > building's Ethernet cable type). > ======================= > Programs that depend on them are engaging in hackery. I am not talking about programs that depend on these interfaces, but humans who need this information themselves. We have trained them over the years to look in syslog for this type of debugging information. >> The best thing to do is to get a centralized logging framework >> implemented under GLD (so logging across disparate drivers is at >> least consistent) and live with what has been habit for so long in >> terms of the log content. OK so far, but Garrett's proposal deletes specific items from the set of things that have been "habit for so long". > That's exactly what this case is attempting to accomplish. The first > step is getting those logging messages into the framework where (if > they exist at all) they belong. I'd agree with all you have said, with the addition of ... without losing the useful information already provided by some of the drivers. By all means, move this reporting into the GLD framework AND ensure that this framework emits messages that actually help admins diagnose and solve common problems. It doesn't help anyone to emit minimal content messages that force all users to look elsewhere for missing contextual data when it is relatively trivial for the framework to provide more context for all. -John
