terminal/console cleanups

Hi,

This is a major cleanup of the uml terminal drivers and console handling (console as in "where the kernel messages go to", not as in "linux virtual consoles). The changes in detail:

(1) There is a new console driver calles "stderr" which (as the name implies) simply dumps all kernel messages to stderr. That one is registered very early in the boot process via console_initcall() and will print every almost kernel message: Both very early in the boot process and very late in shutdown.
Did I mention the kernel panics for me with a kernel mode fault after the "System halted." message? ;)

(2) Ditched the early-console-init hackery in stdio_console.c (open_console(NULL) + related stuff) into the waste basket, not needed any more as you can use the new stderr console driver to get the kernel messages if your kernel crashes very early in the boot process.

(3) Handle console (stdio/serial) initialitation via console->setup() function, which has the nice effect that the console device receives all the kernel messages after setting up the device.

(4) The (2) changes allow a number of further cleanups: As we don't open a line without a tty_struct any more we can ...
* hook struct line into tty->driver_data
* pass around tty_struct instead of struct line everythere
* get rid of some trivial wrappers in ssl.c and stdio_console.c because we can get struct line via tty_struct all the time now.

(5) Fixed a number of Documentation/CodingStyle issues within the code (not systematically, but usually just the places I was touching anyway or where it bugged me while browsing the code because it was hard to read).

Looks like that cleanup also fixed some strange tty issues I've seen in the past (like console getty not responding to input sometimes, suse's /sbin/blogd causing trouble), althrough I havn't tested it that much yet.

Note that with this patch applied it is strongly recommended to specify the device you want to use as console on the kernel command line. The default console is the new stderr console, which has no terminal driver accociated to it, which in turn will make the kernel complain that it can't open a initial console unless you specify one. To get something close to the old behavior use this:

  $ ./linux console=tty1 [ more args ]

My personal favorite is still a serial console setup on hosts terminal, which can be archived this way:

  $ ./linux con=null ssl0=fd:0,fd:1 console=ttyS0 [ more args ]

Note that it is possible to specify multiple consoles, so you can get the messages on both virtual serial line and stderr for example:

  $ ./linux ssl0=xterm console=ttyS0 console=stderr [ more args ]

Enjoy!

Gerd

PS: I'm offline for a week starting in a few hours, so if you want to be
sure I don't miss your reply please send a Cc: directly into my inbox. I usually scan the lists only very briefly after returning from holidays.

diff -pu -ur linux-2.6.5-diff/arch/um/drivers/chan_kern.c linux-2.6.5/arch/um/drivers/chan_kern.c
@@ -138,7 +138,7 @@ int open_chan(struct list_head *chans)
 	return(err);
 }
 
-void chan_enable_winch(struct list_head *chans, void *line)
+void chan_enable_winch(struct list_head *chans, struct tty_struct *tty)
 {
 	struct list_head *ele;
 	struct chan *chan;

@@ -146,13 +146,13 @@ void chan_enable_winch(struct list_head 
 	list_for_each(ele, chans){
 		chan = list_entry(ele, struct chan, list);
 		if(chan->primary && chan->output && chan->ops->winch){
-			register_winch(chan->fd, line);
+			register_winch(chan->fd, tty);
 			return;
 		}
 	}
 }
 
-void enable_chan(struct list_head *chans, void *data)
+void enable_chan(struct list_head *chans, struct tty_struct *tty)
 {
 	struct list_head *ele;
 	struct chan *chan;

@@ -161,7 +161,7 @@ void enable_chan(struct list_head *chans
 		chan = list_entry(ele, struct chan, list);
 		if(!chan->opened) continue;
 
-		line_setup_irq(chan->fd, chan->input, chan->output, data);
+		line_setup_irq(chan->fd, chan->input, chan->output, tty);
 	}
 }
 

@@ -189,21 +189,23 @@ int write_chan(struct list_head *chans, 
 	       int write_irq)
 {
 	struct list_head *ele;
-	struct chan *chan;
+	struct chan *chan = NULL;
 	int n, ret = 0;
 
-	list_for_each(ele, chans){
+	list_for_each(ele, chans) {
 		chan = list_entry(ele, struct chan, list);
-		if(!chan->output || (chan->ops->write == NULL)) continue;
+		if (!chan->output || (chan->ops->write == NULL))
+			continue;
 		n = chan->ops->write(chan->fd, buf, len, chan->data);
-		if(chan->primary){
+		if (chan->primary) {
 			ret = n;
-			if((ret == -EAGAIN) || ((ret >= 0) && (ret < len))){
+			if ((ret == -EAGAIN) || ((ret >= 0) && (ret < len))){
 				reactivate_fd(chan->fd, write_irq);
-				if(ret == -EAGAIN) ret = 0;
+				if (ret == -EAGAIN)
+					ret = 0;
 			}
 		}
-	}
+	}	
 	return(ret);
 }
 

@@ -223,6 +225,20 @@ int console_write_chan(struct list_head 
 	return(ret);
 }
 
+int console_open_chan(struct line *line, struct console *co, struct chan_opts *opts)
+{
+	if (!list_empty(&line->chan_list))
+		return 0;
+
+	if (0 != parse_chan_pair(line->init_str, &line->chan_list,
+				 line->init_pri, co->index, opts))
+		return -1;
+	if (0 != open_chan(&line->chan_list))
+		return -1;
+	printk("Console initialized on /dev/%s%d\n",co->name,co->index);
+	return 0;
+}
+
 int chan_window_size(struct list_head *chans, unsigned short *rows_out,
 		      unsigned short *cols_out)
 {

@@ -465,7 +481,7 @@ int chan_out_fd(struct list_head *chans)
 }
 
 void chan_interrupt(struct list_head *chans, struct work_struct *task,
-		    struct tty_struct *tty, int irq, void *dev)
+		    struct tty_struct *tty, int irq)
 {
 	struct list_head *ele, *next;
 	struct chan *chan;

@@ -491,7 +507,7 @@ void chan_interrupt(struct list_head *ch
 			if(chan->primary){
 				if(tty != NULL) 
 					tty_hangup(tty);
-				line_disable(dev, irq);
+				line_disable(tty, irq);
 				close_chan(chans);
 				free_chan(chans);
 				return;

diff -pu -ur linux-2.6.5-diff/arch/um/drivers/pty.c linux-2.6.5/arch/um/drivers/pty.c
@@ -53,7 +53,8 @@ int pts_open(int input, int output, int 
 	dev = ptsname(fd);
 	sprintf(data->dev_name, "%s", dev);
 	*dev_out = data->dev_name;
-	if(data->announce) (*data->announce)(dev, data->dev);
+	if (data->announce)
+		(*data->announce)(dev, data->dev);
 	return(fd);
 }
 

@@ -93,10 +94,13 @@ int pty_open(int input, int output, int 
 	char dev[sizeof("/dev/ptyxx\0")] = "/dev/ptyxx";
 
 	fd = getmaster(dev);
-	if(fd < 0) return(-errno);
+	if(fd < 0)
+		return(-errno);
 	
-	if(data->raw) raw(fd, 0);
-	if(data->announce) (*data->announce)(dev, data->dev);
+	if(data->raw)
+		raw(fd, 0);
+	if(data->announce)
+		(*data->announce)(dev, data->dev);
 
 	sprintf(data->dev_name, "%s", dev);
 	*dev_out = data->dev_name;

diff -pu -ur linux-2.6.5-diff/arch/um/drivers/xterm.c linux-2.6.5/arch/um/drivers/xterm.c
@@ -125,9 +125,9 @@ int xterm_open(int input, int output, in
 
 	if(data->stack == 0) free_stack(stack, 0);
 
-	if(data->direct_rcv)
+	if (data->direct_rcv) {
 		new = os_rcv_fd(fd, &data->helper_pid);
-	else {
+	} else {
 		err = os_set_fd_block(fd, 0);
 		if(err < 0){
 			printk("xterm_open : failed to set descriptor "

diff -pu -ur linux-2.6.5-diff/arch/um/include/chan_kern.h linux-2.6.5/arch/um/include/chan_kern.h
@@ -8,7 +8,9 @@
 
 #include "linux/tty.h"
 #include "linux/list.h"
+#include "linux/console.h"
 #include "chan_user.h"
+#include "line.h"
 
 struct chan {
 	struct list_head list;

@@ -24,7 +26,7 @@ struct chan {
 };
 
 extern void chan_interrupt(struct list_head *chans, struct work_struct *task,
-			   struct tty_struct *tty, int irq, void *dev);
+			   struct tty_struct *tty, int irq);
 extern int parse_chan_pair(char *str, struct list_head *chans, int pri, 
 			   int device, struct chan_opts *opts);
 extern int open_chan(struct list_head *chans);

@@ -32,9 +34,11 @@ extern int write_chan(struct list_head *
 			     int write_irq);
 extern int console_write_chan(struct list_head *chans, const char *buf, 
 			      int len);
+extern int console_open_chan(struct line *line, struct console *co,
+			     struct chan_opts *opts);
 extern void close_chan(struct list_head *chans);
-extern void chan_enable_winch(struct list_head *chans, void *line);
-extern void enable_chan(struct list_head *chans, void *data);
+extern void chan_enable_winch(struct list_head *chans, struct tty_struct *tty);
+extern void enable_chan(struct list_head *chans, struct tty_struct *tty);
 extern int chan_window_size(struct list_head *chans, 
 			     unsigned short *rows_out, 
 			     unsigned short *cols_out);

diff -pu -ur linux-2.6.5-diff/arch/um/include/chan_user.h linux-2.6.5/arch/um/include/chan_user.h
@@ -42,8 +42,8 @@ extern int generic_window_size(int fd, v
 			       unsigned short *cols_out);
 extern void generic_free(void *data);
 
-extern void register_winch(int fd, void *device_data);
-extern void register_winch_irq(int fd, int tty_fd, int pid, void *line);
+extern void register_winch(int fd,  struct tty_struct *tty);
+extern void register_winch_irq(int fd, int tty_fd, int pid, struct tty_struct *tty);
 
 #define __channel_help(fn, prefix) \
 __uml_help(fn, prefix "[0-9]*=<channel description>\n" \

diff -pu -ur linux-2.6.5-diff/arch/um/include/line.h linux-2.6.5/arch/um/include/line.h
@@ -37,7 +37,6 @@ struct line {
 	struct list_head chan_list;
 	int valid;
 	int count;
-	struct tty_struct *tty;
 	struct semaphore sem;
 	char *buffer;
 	char *head;

@@ -53,8 +52,6 @@ struct line {
 	  init_pri :	INIT_STATIC, \
 	  chan_list : 	{ }, \
 	  valid :	1, \
-	  count :	0, \
-	  tty :		NULL, \
 	  sem : 	{ }, \
 	  buffer :	NULL, \
 	  head :	NULL, \

@@ -69,18 +66,23 @@ struct lines {
 
 #define LINES_INIT(n) {  num :		n }
 
-extern void line_close(struct line *lines, struct tty_struct *tty);
+extern void line_close(struct tty_struct *tty, struct file * filp);
 extern int line_open(struct line *lines, struct tty_struct *tty, 
 		     struct chan_opts *opts);
 extern int line_setup(struct line *lines, int num, char *init, 
 		      int all_allowed);
-extern int line_write(struct line *line, struct tty_struct *tty, int from_user,
-		      const char *buf, int len);
+extern int line_write(struct tty_struct *tty, int from_user,
+		      const unsigned char *buf, int len);
+extern void line_put_char(struct tty_struct *tty, unsigned char ch);
+extern void line_set_termios(struct tty_struct *tty, struct termios * old);
+extern int line_chars_in_buffer(struct tty_struct *tty);
 extern int line_write_room(struct tty_struct *tty);
+extern int line_ioctl(struct tty_struct *tty, struct file * file,
+		      unsigned int cmd, unsigned long arg);
 extern char *add_xterm_umid(char *base);
-extern int line_setup_irq(int fd, int input, int output, void *data);
+extern int line_setup_irq(int fd, int input, int output, struct tty_struct *tty);
 extern void line_close_chan(struct line *line);
-extern void line_disable(struct line *line, int current_irq);
+extern void line_disable(struct tty_struct *tty, int current_irq);
 extern struct tty_driver * line_register_devfs(struct lines *set, 
 				struct line_driver *line_driver, 
 				struct tty_operations *driver,

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Excellent! I've been wanting to do this for a long time, but haven't had the spare time.

I haven't looked at the actual changes, but this all sounds right.

Except for this. I don't want to break everyone's scripts. I think maybe some logic similar to the root= might be in order, where it checks to see if a console was specified, and if not, adds one to the command line.

Jeff

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Nice! Does this also mean the UML console no longer interferes with the normal virtual console subsystem? Before it was not possible to enable CONFIG_VT without some serious surgery to the UML vc subsystem, because both tried to attach to the same device number.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

No, that hasn't changed. Guess you are asking because of the uml virtual framebuffer driver, where you want run fbcon on top of?

I'm not sure how to deal with that best.

Right now in UML /dev/tty[0-8] are simple terminal lines. /dev/tty0 hasn't the special meaning of "current foreground console" as there are simply no virtual consoles. It is possible to use screen to build a virtual-console like setup in a pure text-based environment, which works pretty good.

It likely would also be possible to use CONFIG_VT and create a CONFIG_VT_UMLCON driver instead. Havn't looked at that. I hope going that route doesn't mean we'll have to implement something like screen inside the uml kernel ...

By moving the stderr console code to another source file it should at least be possible to make the uml consoles a compile time option and then be able to use fbcon instead.

Gerd

Smoking Crack Organization


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Indeed.

Wouldn't it be more logical to have a separate type of device for UML virtual consoles using xterms?

Indeed.

Good. As long as I can have a stderr console and CONFIG_VT, I'm happy.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

The point of the uml console is that existing apps expecting /dev/tty[0-8] being present don't cry for help because they don't exist ;)

Creating a separate device type (and thus separate special files) for them doesn't make much sense. You can already use virtual serial lines to get that if you want, and it works better than something completely new because most distributions know how to handle a serial console.

There are still issues with some apps as they expect several ioctls() work on /dev/tty[0-9] which don't work inside a UML machine. Some of these would likely go away when switching over to ...

... such a setup.

While thinking about it: A kernel parameter to disable that at runtime should work fine as well. With my patch the uml console is in no way special any more, it's just a tty driver, skipping the register and unregister calls when some variable is set should be no problem.

Gerd

Smoking Crack Organization


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

I think this will be hard without first giving UML a virtual framebuffer, allowing the framebuffer console to be used.

The concept of VT consoles on character I/O consoles like UML stdio or Serial lines is not precisely in line with how CONFIG_VT works..

Indeed, and this would allow for normal VT console operation.

It should also not be hard (if not done already) to make the UML VT "emulation" a compile option separate from the stdio console.

Regards
Henrik

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Indeed. And that's what I'm working on (sometimes, too many things to do).

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel