On May 29, 2007, at 3:09 PM, James Carlson wrote: > John Plocher writes: >> James Carlson wrote: >>> ... and then what, exactly? Abandon all engineering sense >> >> This sounds like an overreaction. > > So where in any of our documentation do we make the contents of those > messages any sort of stable interface?
It's *syslog* we're talking about here. If one feels the need to syslog something, they're unwittingly (or purposefully) committing themselves to a /de facto/ Public interface. There's nothing the kernel does with the text, and syslog isn't there to fill disk space. Just like the words you write in this PSARC thread, stuff in syslog is on the Public record, read by Joe Admin and scraped by Jane Developer. Moral of the story: be careful what you say (read: log) because it may come back to haunt you. Considering the intended audience of syslog's output, and how long these network status messages have been around in particular, it might be prudent to yield away from "pure architecture" (as someone put it) in this case and not try to close the barn door... not only because the horse has already left, but you'll be shutting it on a lot of users' feets. 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. There's a battle between architecture and consistency here. Each have their strengths and good points, but when the two come into conflict it's best to see things in the larger context of what the thingy is. In this particular case, I would vote for consistency over architecture, with a compromise favoring the latter. Keep the logged text consistent with history, and move logging into GLD. <amused sarcasm> Hell, I'd say if there was a way to refuse to load a LAN driver that does anything above cmn_err(CE_PANIC,...) , we should. </amused sarcasm> /dale
