On Tue, May 29, 2007 at 03:09:30PM -0400, James Carlson wrote: > John Plocher writes: > > Mostly harmful? In the scope of this case, how is having > > link status, speed and duplex considered harmful - or even > > only semi-usable? > > Links flapping in the breeze cause log files to fill and overflow with > garbage, causing users to be unable to find any relevant messages, and > sometimes causing file systems to fill up. > > Different drivers issue completely different messages in different > contexts, and these cause customers to get annoyed or confused.
Since this particular case merely removes items from log messages, rather than removing log messages, and given the strong opinions stated so far in favor of keeping the information that would be removed, what is the harm of keeping said information in said log messages? Whatever the interface status of log messages, if it's easy for us to keep the messages as they are/were then we should. If a case were to propose replacing one system component with a different implementation, particularly an implementation done outside Sun, then the effort to ensure that the new implementation has the same/ similar log messages as/to the old implementation would likely be prohibitive, and we could then invoke the "log messages are not an interface" dictum. As for whether the "log messages are not an interface" dictum applies here, they most certainly are at least intended for human consumption, and humans do consume these particular messages, so "log messages are not an interface" seems inappropriate to invoke here. Telling users to use some other tool to get additional information related to specific log messages seems more than OK to me, particularly for new messages or rarely used old messages. But in this case the messages in question are: a) old, b) very commnly relied-upon by users; this makes the proposed change more like a regression than like progress. Now, from the i-team's p.o.v., moving logging of link state changes from the driver to the framework may be simple, while similarly moving logging of speed/ duplicity change logging, and adding link state, speed and/or duplicity data to these log messages may be not so simple. This may be because the method by which the driver informs the framework of such changes does not allow the driver to provide all that information to the framework, so then the framework must go query the driver to get the remaining data so it can be logged -- logging the call from the driver and its arguments being easy while querying other device state from the driver not. But that's still a lot less effort than retrofitting a new implementation with log messages to match an old one. So don't break the customer's expectations -- it does not seem difficult to meet them in this case. Alternative: don't move the logging to the framework. If the motivation for the move was consistency across drivers then perhaps a common framework log routine for each media type would be better (e.g., ethernet would log link state, speed and duplicity). Nico --
