Re: [PATCH] detour TTY driver - now ttyprintk

[Greg KH <gregkh@suse.de>]

On Wed, Aug 25, 2010 at 12:09:57AM +0200, Samo Pogacnik wrote:
> On 24.08.2010 (Tue) at 14:10 -0700 Greg KH wrote:
> > On Tue, Aug 24, 2010 at 10:57:50PM +0200, Samo Pogacnik wrote:
> > > On 25.06.2010 (Fri) at 12:03 +0100 Alan Cox wrote: 
> > > > With my devices.txt owner hat on I'll allocate the minor as you suggest
> > > > (and double check this causes no problems), with my tty hat on can you
> > > > send it to GregKH for merging into the tree.
> > > 
> > > Hi,
> > > 
> > > I hope that this TTY driver is ok for merging. It is very basic -
> > > removed all flow control and rate limiting. Patch has been generated
> > > against 2.6.34 kernel version.
> > > 
> > > Ttyprintk is a pseudo TTY driver, which allows users to make printk messages,
> > > via output to ttyprintk device. It is possible to store "console" messages
> > > inline with kernel messages for better analyses of the boot process, for
> > > example.
> > 
> > Why does this need to be a tty driver?  Why not a misc device?
> Thanks for the response. I'll try to explain.
> Well it all started with a kernel hack, which internaly redirected
> console output to printk function to be able to capture console messages
> inline with real kernel messages. Console messages have also been
> automatically stored via system logging facility, which was very useful
> especially for analyzes of the initrd part of the userspace system
> initialization. Through initial posts (thread: console logging detour
> via printk) Alan suggested, that a separate TTY driver could provide
> this functionality and that may initial hacking isn't acceptable.

That's what kmsg can do :)

> > And what about the normal way of just writing to /dev/kmsg to do this?
> > Why a whole new driver for this same functionality?
> I must admit, i was not aware of the /dev/kmsg driver, but i made a few
> tests and found out that it seems not to be possible to redirect console
> to kmsg.

See how systemd does this, as it sounds like exactly what you want to
do.  Look in either Fedora 14, or openSUSE Factory for examples of this,
with no kernel changes needed.

thanks,

greg k-h