RE: [patch] printk subsystems

["Perez-Gonzalez, Inaky" <inaky.perez-gonzalez@intel.com>]

> From: Karim Yaghmour [mailto:karim@opersys.com]
>
> 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.

But you don't need to provide buffers, because normally the data
is already in the kernel, so why need to copy it to another buffer
for delivery?

That's the point I tried to address with the kue patches I posted 
last week - once you have the data, wherever, you just queue it
for delivery, and provide the delivery subsystem for means to 
destroy it when it is delivered (and thus, not needed anymore)
[currently I only support kfree(), but I plan to add a destructor
function that at the same time can work as a callback for delivery].

This is where I think relayfs is doing too much, and that is the
reason why I implemented the kue stuff. It is very lightweight
and does almost the same [of course, it is not bidirectional, but
still nobody asked for that].

Cheers,

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)