login
Search
Hi, Here is the initial suggestion for a simple detour TTY driver, which provides the ability to write user messages through printk. This allows user output to be inlined with kernel output. Together with printk time-stamping enabled, a detailed boot sequence analyses is possible. Additionally, console logs could have been stored through the same mechanism as kernel messages and does not require the system logger to be started very/too soon. regards, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux-2.6.33.3/Documentation/devices.txt b_linux-2.6.33.3/Documentation/devices.txt index 53d64d3..f889097 100644 --- a_linux-2.6.33.3/Documentation/devices.txt +++ b_linux-2.6.33.3/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/detour Detour via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux-2.6.33.3/drivers/char/Kconfig b_linux-2.6.33.3/drivers/char/Kconfig index e023682..4d21e2d 100644 --- a_linux-2.6.33.3/drivers/char/Kconfig +++ b_linux-2.6.33.3/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config DETOUR_TTY + bool "TTY driver to detour user output via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/detour. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux-2.6.33.3/drivers/char/Makefile ...
Hi again, This version of patch provides the ability to initially redirect console to "detour TTY" (on driver initialization), if "detour" boot command line option is set. best regards, Samo p.s. Randy, Alan: Would you be so kind to comment on usability and acceptability of this tty driver approach? Thanks. --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..f889097 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/detour Detour via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/Documentation/kernel-parameters.txt b_linux/Documentation/kernel-parameters.txt index 839b21b..1fd9f09 100644 --- a_linux/Documentation/kernel-parameters.txt +++ b_linux/Documentation/kernel-parameters.txt @@ -623,6 +623,8 @@ and is between 256 and 4096 characters. It is defined in the file Defaults to the default architecture's huge page size if not specified. + detour [KNL] Initial console redirect via detour tty. + dhash_entries= [KNL] Set number of hash buckets for dentry cache. diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..f81781d 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,21 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config DETOUR_TTY + bool "TTY driver to detour user output via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline ...
Not sure the naming is ideal (detour what where, simply calling it module parameters can be set compiled in with modulename.option=foo so The kernel really expects posix behaviour but I'm not sure how much it really matters in this case. Fixing that isn't hard though (use tty_port No. The behaviour of a tty is very precisely defined by the standards and stomping over things you shouldn't is not good at all. Remember your tty sets its own initial termios settings so you can set those to give the initial behaviour you want. You need the tty layer here in your case anyway as you don't have sufficient locking otherwise ! Also I'd provide a write_room method which always answers 'lots' Do you need a recursion check. Suppose I open this device and capture printk console messages to it ? Alternatively maybe you need an ioctl Bletch.. I'm really opposed to this kind of hackery. Fix your userspace a tiny bit. So - Write only tty that uses printk: Looks good to me, implementation quibbles only - Magic kernel hacks to shuffle things around in the initial console logic - hideous. I still really think you need to fix your userspace --
That alone is enough for a NAK. Do Not Do That. Fake struct file/dentry/inode and their uses are not acceptable. Neither is modifying file_operations, while we are at it. --
Thank you for all comments. I'll try to follow them (might take some time) and i'll remove the internal console redirection magic for sure. regards, Samo --
Hi, This is another version of former detour TTY driver, trying to follow Alan's suggestions: - renamed from detour to ttyprintk - removed possibility for initial internal redirection of console to this tty - providing hopefully more proper open/close tty operations - fixed initial termios settings - added primitive write_room operation - added ratelimting support (recursion check) and an ioctl trap to catch ratelimiting being activated. i'd appreciate a suggestion on this ioctl command naming/value and on location of its definition? - additional error checking I also have a question about the tioccons() function from the tty_io.c. Should this function also check, if the redirection tty has been opened for writing, since there are going to be implicit writes to this tty for each console message? This would prevent users without write permissions to successfully perform TIOCCONS ioctl. This would also prevent writing capable users to successfully perform TIOCCONS with read-only opened tty, but failing to write console messages to the redirection tty afterwards. This seems to happen because the mode of opened tty at the time of issuing TIOCCONS ioctl is remembered. Alan, could you please give the patch bellow another look? thanks, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ ...
You can replace the rest with
return tty_port_open(port, tty, filp);
and
These two can't happen if you use tty_port_* so it is better to blow up.
And this is serialized by the caller (not that having your own lock is
Ok that wasn't quite what I had in mind.
What I was thinking was needed was this
/* Stop TIOCCONS */
case TIOCCONS:
return -EOPNOTSUPP;
only it won't work that way. I'll sort that out in tty_io.c once the
driver is happy. That way anything trying to mis-redirect the console
The one other bit you will need to use the helpers is
struct tty_port_operations null_ops = { };
tpk_port.port->ops = &null_ops;
Alan
--
I'm thinking to leave the ratelimit support in for the time being. I had in mind cases, when someone does "cat /proc/kmsg > dev/ttyprintk" or suppose the console is redirected to ttyprintk (which i would like to be able to do from user program) and then someone does: "cat /proc/kmsg > /dev/console"... or if console is redirected after this command ? Were you thinking of some other mis-redirection case? Samo --
Console as in the printk sense would then loop.
If you are going to do the flow control you should probably do something
like
write_room()
{
if (!flow_controlled)
space = 8192;
return space;
}
write()
{
space -= len;
}
then your flow control will behave properly and slow down users rather
than losing data (except stuff sent without blocking)
--
For correct flow control, i suppose current empty space of the real (final) printk buffer is needed. On the other hand my intermediate pre-formatting buffer is only "one line" long, but serialized on access in a way that it is always completely available (except for the time of tpk_printk() function running). As such intermediate buffer only defines maximum write_room space. Now there are two ideas. The first one is to dig out current real printk buffer space (smells like hacking?) and adapt write_room to that space in some logical manner. And the other would be to use ratelimit support to switch between max and zero in write_room answer and remove other retelimit response? What do you suggest, do i miss something? regards, Samo --
Console drivers have their own buffering so that doesn't really work. If you want to just avoid explosions then you don't need to be quite so Yes - except that a driver isn't permitted to reduce the write room space by more than bytes written. That is if you offer 512 bytes you can't offer 0 until 512 bytes have been written - hence the design of the pseudo code I posted in the previous message. --
Now flow control is provided in a way that each write ratelimit false detection shrinks available space for its output lenth. On the other hand write returns available space back to maximum on true ratelimit detection result. Additionaly each next write_room returns at least one character space under high load, if zero space is reached. Additionally a private ttyprintk_ratelimit function is provided to suppress "missed callbacks" printks, because we do not really miss anything. regards, Samo ---- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile ...
That won't do what you think, the ldisc will keep seeing progress and generate millions of 1 byte I/Os in a loop ! And I'll fix this bit up to work properly in the core code. 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. --
I thought that this would automatically reduce processor load, which is obviously not the case. Sorry for the delay, but i am trying to figure out how to slow down write method when under pressure. And that setting tpk_space to 1 would then be just in case we reach 0 to enable further processing. Samo --
Ok I played with this a bit. Much to my surprise until I thought about it in detail it all works fine without any of the ratelimiting at all. There is a problem if you manage to redirect the console *in kernel* to the printk driver, but that needs stopping anyway and rate limit won't fix it (you blow the stack before it kicks in) In the case where userspace loads it hard and its a graphical console then we use a lot of CPU power drawing stuff on screen, but killing the process does as is expected. With a serial console the printk itself blocks which blocks the line discipline which in turn slows stuff down. The only two bad things I can see how to cause are - Slowing down output by stuffing lots of extra data into the port (which I can do anyway just fine) so isn't worse than before. - Filling up the dmesg log easily and hiding important messages. Not really a problem in this case bcause the whole point of this is embedded and capturing those messages as if they were system ones. So much to my surprise the flow control is a red herring and best left out. Alan --
If without flow control, do you think it makes sense to very slowly introduce more and more delay (interruptible) into tty's write operation when output rate is "too" high? That way non-error conditions would not suffer (not discarding any messages, only delaying additional 1 msec on 100 writes), when ratelimit would have been exceeded from time to time. And on the other hand endless high-volume output, which is probably an error condition, would slowly give away more and more of its processing time. Maybe this would also help if output is made on behalf of some high RT-prioritized process? Of course, i can easily remove ratelimiting as well, if the situation with flow control isn't clear and this only complicates things. Samo --
Hi, Please bear with me for a bit longer, because i got slightly modified perspective of some things i did within the driver. I.e. somewhere down the road i forgot that my pre-formatting function does not really limit output buffer size with its "one-line" buffer size. So now 4K output size is assumed and always provided by write_room(). The other thing is that i tried to resolve two things being in conflict. I tried to fit driver to existing distro initialization, which required immediate output also for not line terminated strings. And on the other hand not line terminated strings could have been provided by line discipline all the time. So i finally removed immediate output code and let user takes care by terminating lines if immediate output is required. There is additional possibility to fine tune ratelimiting and printk delaying parameters via defines also with more comments added. Alan, if you agree, i would send this one to GregKH? regards, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y ...
Somewhat changed to slowly increase delay in write, if ratelimiting I am not sure if i understand. Should i exclude devices.txt from patch before sending it to GregKH? Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ...
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. regards, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += ...
I need some information on what this patch is, and why we would want it, so that it can be put into the changelog. Care to resend it with that information present? thanks, greg k-h --
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. regards, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- ...
Why does this need to be a tty driver? Why not a misc device? And what about the normal way of just writing to /dev/kmsg to do this? Why a whole new driver for this same functionality? confused, greg k-h --
> Why does this need to be a tty driver? Why not a misc device? So you can use it as a"console" (in the user space sense) tty device on embedded devices which don't have a meaningful normal output subsystem. Alan --
But can't you do that today with kmsg? The startup of systemd does this in a way that handles all of the log messages very nicely, and the embedded people are sure to pick it up as well because of the simplicity. thanks, greg k-h --
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 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. regards, Samo --
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 --
I'll check out systemd. however:) It may be that systemd does not cover the initrd part of the initialization and it may be an overkill do introduce systemd to an existing system just to be analyzed. regards, Samo --
No, it does cover that. You should be able to do that with a simple console redirection to /dev/kmsg What happened when you tried to do that? thanks, greg k-h --
stty: standard input: Inappropriate ioctl for device It's value is twofold - formatting - tty ioctls work as they should on a console (eg vhangup) and its a tiny driver with no impact on the rest of the kernel - so to me it seems useful in that form. Alan --
Ick, we really want to format things from userspace here? thanks, greg k-h --
Depends what you are trying to do. Put an embedded hat on Do you want to be able to flip between a real debug interface and a logging device on the same software set without risking changing behaviour Do you want to load a 70K daemon and an initrd or burn about 1.5K on a kernel interface ? Alan --
I'd rather burn 0K on the one we have today :) Seriously, look at how Fedora 14 handles this, why can't you do the same for embedded systems all from userspace, no additional code needed anywhere. thanks, greg k-h --
Samo sometimes ago I gave you some information on the system startup about OpenSuse, have you look at it? It's possible that what Greg said, it's true. Regards, Marco --
A tty has a very specific set of behaviours simply by being a tty. Some applications rely upon them so being able to flip between the two Its a whole set of extra processes and daemons and stuff, and minimally uses something like 70K even if its very compact (8K stack, 40K+ page tables, 16K of buffers, code, data) - oh and I forgot the fifo buffering and pty cost - so its near 100K. 1.5K v 100K - for something 1.5K of kernel code that anyone else can turn off and would be off by default ? On a lot of embedded systems you don't have all the stuff Fedora carts around. No modules, initrds, magic front end processes, graphical startup daemons etc, all of which work to produce that feature IFF you have pty support in your kernel, and for the current code also glibc. You also want errors to get out (or stored) even if there are crashes - which the Fedora one is not very good at. To be fair in the Fedora world its not a big deal to say 'Oh dear, boot with ....'. Embedded isn't the same, and you want to capture the odd rare error reliably. Alan --
exec < /dev/console > /dev/kmsg 2>&1 again, the above exec line should work for what the embedded people want, right? thanks, greg k-h --
> Would that work for this driver in use as a console? We didn't *need* devtmpfs either - that was a little bit of user space. It's a similar thing - you can do the job better in 1.5K of kernel code than 150K or more of user space - which is not trivial on a box with no swap. Alan --
Fair enough. So, with this driver, would it make sense for the distros Ok, I didn't realize it really was that big. Samo, care to resend the patch? thanks, greg k-h --
Distros no - I doubt any normal PC distro would turn the facility on. libc page tables app page tables stacks (kernel and user) arguments/exec page buffers Yes - it soon adds up. Alan --
So should this be dependent on CONFIG_EMBEDDED then? thanks, greg k-h --
On Wed, 25 Aug 2010 11:16:47 -0700 No objection to that --
Should i resend the patch with CONFIG_EMBEDDED dependency enabled? I do not have any real objections to that, except that the driver operates the same way regardless of the (non-)embedded configuration. regards, Samo --
No, I can change it when I apply the patch next week (sorry, swamped at the moment.) thanks, greg k-h --
Sure, here it is: --- 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. regards, Samo --- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- ...
Systemd does not steal the console, this is done by plymouth, in the same way blogd can do that. It uses a pty and rewrites the messages. Systemd does pass syslog to the kernel buffer during early boot. Init provides /dev/log. With systemd, the started services usually don't get the console connected, but use syslog anyway or the stdout/err gets redirected to syslog. With systemd the console is not too useful because we start everything in parallel. If all the services would put out stuff there like sysv did, it would look like a real mess. Kay --
Or isn't that what you asked for? We just write the stuff that arrives at syslog to /dev/kmsg to put things in the kernel log buffer. Also initrds are usually using exec < /dev/console > /dev/kmsg 2>&1 to get stuff directly to the kernel buffer. What does /dev/ttyprintk offer on top of that? Kay --
Also added, with many thanks, Samo ---- Signed-off-by: Samo Pogacnik <samo_pogacnik@t-2.net> diff --git a_linux/Documentation/devices.txt b_linux/Documentation/devices.txt index 53d64d3..71aef33 100644 --- a_linux/Documentation/devices.txt +++ b_linux/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 diff --git a_linux/drivers/char/Kconfig b_linux/drivers/char/Kconfig index 3141dd3..5c38a06 100644 --- a_linux/drivers/char/Kconfig +++ b_linux/drivers/char/Kconfig @@ -485,6 +485,20 @@ config LEGACY_PTY_COUNT When not in use, each legacy PTY occupies 12 bytes on 32-bit architectures and 24 bytes on 64-bit architectures. +config TTY_PRINTK + bool "TTY driver to output user messages via printk" + default n + ---help--- + If you say Y here, the support for writing user messages (i.e. + console messages) via printk is available. + + The feature is useful to inline user messages with kernel + messages. + In order to use this feature, you should output user messages + to /dev/ttyprintk or redirect console to this TTY. + + If unsure, say N. + config BRIQ_PANEL tristate 'Total Impact briQ front panel driver' depends on PPC_CHRP diff --git a_linux/drivers/char/Makefile b_linux/drivers/char/Makefile index f957edf..ed60f45 100644 --- a_linux/drivers/char/Makefile +++ b_linux/drivers/char/Makefile @@ -11,6 +11,7 @@ obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o tty_ldisc.o tty_buffer.o t obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o +obj-$(CONFIG_TTY_PRINTK) += ttyprintk.o obj-y += misc.o obj-$(CONFIG_VT) += vt_ioctl.o vc_screen.o selection.o keyboard.o obj-$(CONFIG_BFIN_JTAG_COMM) += ...
