Martin Hicks wrote:
> I don't think relayfs solves the problem either. This just adds an
> extra dependency for yet another pseudo-filesystem. printk is something
> that needs to "just work" even if the kernel is in the midst of
> crashing. Adding the extra complexity of all printk going out through a
> filesystem/buffer layer is not desirable, IMHO.
I beg to differ. There's a point where we've got to stop saying "oh,
this buffering mechanism is special and it requires its own code."
relayfs is there to provide a unified light-weight mechanism for
transfering large amounts of data from the kernel to user space.
> It seems that the relayfs solution for buffer overflows in the printk
> buffer is to just make lots of buffers. I really want to be able to
> turn off prink logging for stuff I don't care about, without the
> complexity of having fifteen different logs to look in and changing
> how get get log info from the kernel to syslog.
Again, as I said earlier, relayfs doesn't care about filtering. That's
to the upper layers to take care of. It so happens that relayfs simplifies
filtering by allowing the upper layers to mux their data using separate
channels. In no way is anyone forced to do that, though. It's there if
you need it, and if you need to simply have a is_this_message_logged()
function, then so be it, but that's yours to implement.
As for buffer overflows and printk, automatically resizeable log buffers
using a water-mark scheme are on the relayfs to-do list.
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/
This archive was generated by hypermail 2b29 : Wed Apr 23 2003 - 22:00:22 EST