Messages in this thread | | | Date | Tue, 15 Apr 2003 14:40:06 +0000 | From | Karim Yaghmour <> | Subject | Re: [patch] printk subsystems |
| |
Martin Hicks wrote: > I'm not sure that this addresses the core problem that I'm trying to > deal with. The problem is that machines with certain configurations > (large number of CPUs, Nodes, or a bunch of SCSI and disks) display far > too many messages to the console, resulting in the log buffer being > overflowed. The method that I'm proposing simply allows you to decide > what gets logged when a printk() happens, depending on the message's > priority and which subsystem it originated from.
I'm not going to address the "filtering" aspect of the problem, but I would like to point out that this issue of printk overflowing and having multiple streams of printk is already solved by relayfs: http://www.opersys.com/relayfs/
With relayfs, one could easily have multi-channel printks (e.g. one for each "subsystem" and a main one for important messages of all subsystems.) The advantages of relayfs are obvious: - No more lost printks. - A unified buffering scheme for all subsystems that need to send data to user-space. - Lockless per-cpu buffering. - etc.
We've already started playing around with printk on relayfs, though we don't have code to offer at this time.
In terms of init-time printk'ing with relayfs, this is the scheme I suggest: - Change all statically allocated printk buffers to __initdata. - Add a registration function in kernel/printk.c which is called during initialization. - Said function: 1) Allocates relayfs channel(s) 2) Atomically copies existing init-time data to channel 3) Starts using relayfs channel for all future transfers
That's it. Thereafter, all statically allocated printk buffers are dropped and all buffer management is left to relayfs.
[The filtering aspect is not taken care of by relayfs because it is not part of its "mandate". relayfs only aims at providing a very reliable lightweight high-speed data transfer mechanism for providing kernel data to user space. Higher-level mechanisms can easily use different relayfs channels to filter/mux data.]
Karim
===================================================
Karim Yaghmour karim@opersys.com Embedded and Real-Time Linux Expert =================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |