a) the subject line did not get attention, or
b) ???
Anyway, vis-a-vis prioritizing kernel messages and throttling
them at compile, generation and display times:
Riley Williams wrote:
> >>> Perhaps an even simpler option would be to have these messages
> >>> sent as KERN_DEBUG ones, as those are by default ignored, but can
> >>> be enabled by adding or tweaking an entry in /etc/syslog.conf - I
> >>> now have all KERN_DEBUG level messages sent to
> >>> /var/log/kernel.debug so I can check what's going on...
>
> >> I've opted, as per Alan's suggestion, to make it a sysctl option
> >> instead (toggled using the /proc/sys filesystem). A lot cleaner
> >> and easier to play with, imho.
>
> >> Copy of the patch sent to the kernel list, and also to Alan for
> >> him to hopefully implement.
>
> > I offered before, and I want to repeat my offer. Some years ago
> > (about 5), I implemented kernel events in the SVR4.2/ESMP (well, a
> > variant of it) that basically replaced the printf's and could have
> > replaced the cmn_err() calls.
>
> I have to admit it sounds interesting, but wonder what Linus and Alan
> think...
>
> > It has the following benefits:
>
> > 1. All but panic level events can be compiled out and/or suppressed
> > by category and severity level. Actually, there were three
> > methods:
>
> > a. Compilation suppression (most often suppressing DEBUG, TRACE
> > and INFO level messages)
> > b. Generation suppression (each category (file system, memory,
> > etc.) has a threshhold)
> > c. Display suppression (the console event monitor had a category
> > or level suppression mechanism as well)
>
> Personally, I'd say that a variant on that would be more useful: Have
> them suppressed from the display, but filed away in a file somewhere
> so they can be accessed when required...
a, b and c are independent throttles. Naturally, it does no good
to have b less restrictive than a, nor c less restrictive than b or a.
Every event generated would be stored in a log, so
if b is more restrictive than c, then there would be, in fact, events
stored that were not displayed on the console.
> > 2. Significant reduction in locked memory requirements (other than
> > the panic messages, all the formatting strings were moved to
> > user space) syslogd was modified to detect events that needed to
> > be formatted
>
> That sounds VERY interesting...
>
> > 3. Internationalization sans the getmsg() calls is facilitated by
> > collecting the formatting strings into just a few files that can
> > be translated and compiled into a specific-language kernel.
>
> That is almost a direct consequence of the previous point...
>
> > 4. There is a phased approach to all this that works. Phase 1 would
> > make all the "printk()" calls macros and enable the compile-out
> > feature. Everything else would come later.
>
> That throws up an interesting question: Is it possible to write a
> macro that takes a variable number of parameters, like printk() does?
>
> > 5. "printk()" would remain for externally supplied drivers, though
> > there would also be an event interface available as well.
>
> > If this appears interesting, I would do a trial phase one
> > implementation in some area in the kernel (e.g. mm).
>
> The area that would probably benefit most from it would be fs rathen
> than mm, at least from the volume of printk's therein...
>
> > If *that* looks okay, I would propose doing it in the 2.3.x kernel.
>
> I'd be interested in helping with it as well...if I have time...
Always the problem. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/