I'm not seriously proposing this. But, as far as I can tell, this
information isn't exposed to userspace anywhere, and it's a useful
thing to know. I'm certainly open for better ideas on how to expose
this (sysfs attributes? other?)
....
The attached patch adds /proc/tty/console. The contents of it are
simply a description of the current drivers attached to /dev/console.
For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
yield:
# cat /proc/tty/console
unknown /dev/tty0
serial /dev/ttyS3
Bill
---
diff -ru linux-2.6.24.noarch/fs/proc/proc_tty.c linux/fs/proc/proc_tty.c
--- linux-2.6.24.noarch/fs/proc/proc_tty.c 2008-02-27 12:50:59.000000000 -0500
+++ linux/fs/proc/proc_tty.c 2008-02-27 12:25:54.000000000 -0500
@@ -6,6 +6,7 @@
#include <asm/uaccess.h>
+#include <linux/console.h>
#include <linux/init.h>
#include <linux/errno.h>
#include <linux/time.h>
@@ -129,6 +130,38 @@
return seq_open(file, &tty_drivers_op);
}
+static int show_tty_console(struct seq_file *m, void *v)
+{
+ int index;
+ struct console *c;
+
+ for (c = console_drivers; c ; c = c->next) {
+ struct tty_driver *t = NULL;
+ if (!c->device)
+ continue;
+ t = c->device(c, &index);
+ seq_printf(m, "%-20s", t->driver_name ? t->driver_name : "unknown");
+ seq_printf(m, "/dev/%s%d", t->name, c->index);
+ seq_printf(m, "\n");
+ }
+ return 0;
+}
+
+static void *c_start(struct seq_file *m, loff_t *pos)
+{
+ return *pos == 0 ? &c_start : NULL;
+}
+
+static void *c_next(struct seq_file *m, void *v, loff_t *pos)
+{
+ ++*pos;
+ return c_start(m, pos);
+}
+
+static void c_stop(struct seq_file *m, void *v)
+{
+}
+
static const struct file_operations proc_tty_drivers_operations = {
.open = tty_drivers_open,
.read = seq_read,
@@ -136,6 +169,25 @@
.release = seq_release,
};
+static const struct seq_operations tty_console_op = {
+ .start = c_start,
+ .next = c_next,
+ .stop = c_stop,
+ .show = show_tty_console
+};
+
+static int tty_console_open(struct inode *inode, struct file *file)
+{
+ return seq_open(file, &tty_console_op);
+}
+
+static const struct file_operations proc_tty_console_operations = {
+ .open = tty_console_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release
+};
+
/*
* This is the handler for /proc/tty/ldiscs
*/
@@ -230,4 +282,7 @@
entry = create_proc_entry("tty/drivers", 0, NULL);
if (entry)
entry->proc_fops = &proc_tty_drivers_operations;
+ entry = create_proc_entry("tty/console", 0, NULL);
+ if (entry)
+ entry->proc_fops = &proc_tty_console_operations;
}
On Wed, 27 Feb 2008 13:18:57 -0500 Bill Nottingham wrote:
> I'm not seriously proposing this. But, as far as I can tell, this
> information isn't exposed to userspace anywhere, and it's a useful
> thing to know. I'm certainly open for better ideas on how to expose
> this (sysfs attributes? other?)
>
> ....
>
> The attached patch adds /proc/tty/console. The contents of it are
> simply a description of the current drivers attached to /dev/console.
> For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> yield:
>
> # cat /proc/tty/console
> unknown /dev/tty0
> serial /dev/ttyS3
>
So it omits other consoles (non-tty) intentionally?
or does it include them even though the procfs filename contains "tty"?
Anyway, I'd like to see something like this.
Compare http://www.xenotime.net/linux/patches/consoles-list.patch
(April-2006).
>
> ---
> diff -ru linux-2.6.24.noarch/fs/proc/proc_tty.c linux/fs/proc/proc_tty.c
> --- linux-2.6.24.noarch/fs/proc/proc_tty.c 2008-02-27 12:50:59.000000000 -0500
> +++ linux/fs/proc/proc_tty.c 2008-02-27 12:25:54.000000000 -0500
> @@ -6,6 +6,7 @@
>
> #include <asm/uaccess.h>
>
> +#include <linux/console.h>
> #include <linux/init.h>
> #include <linux/errno.h>
> #include <linux/time.h>
> @@ -129,6 +130,38 @@
> return seq_open(file, &tty_drivers_op);
> }
>
> +static int show_tty_console(struct seq_file *m, void *v)
> +{
> + int index;
> + struct console *c;
> +
> + for (c = console_drivers; c ; c = c->next) {
> + struct tty_driver *t = NULL;
> + if (!c->device)
> + continue;
> + t = c->device(c, &index);
> + seq_printf(m, "%-20s", t->driver_name ? t->driver_name : "unknown");
> + seq_printf(m, "/dev/%s%d", t->name, c->index);
> + seq_printf(m, "\n");
> + }
> + return 0;
> +}
> +
> +static void *c_start(struct seq_file *m, loff_t *pos)
> +{
> + return *pos == 0 ? &c_start : NULL;
> +}
> +
> +static void *c_next(struct seq_file *m, void *v, loff_t *pos)
> +{
> + ++*pos;
> + return c_start(m, pos);
> +}
> +
> +static void c_stop(struct seq_file *m, void *v)
> +{
> +}
> +
> static const struct file_operations proc_tty_drivers_operations = {
> .open = tty_drivers_open,
> .read = seq_read,
> @@ -136,6 +169,25 @@
> .release = seq_release,
> };
>
> +static const struct seq_operations tty_console_op = {
> + .start = c_start,
> + .next = c_next,
> + .stop = c_stop,
> + .show = show_tty_console
> +};
> +
> +static int tty_console_open(struct inode *inode, struct file *file)
> +{
> + return seq_open(file, &tty_console_op);
> +}
> +
> +static const struct file_operations proc_tty_console_operations = {
> + .open = tty_console_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = seq_release
> +};
> +
> /*
> * This is the handler for /proc/tty/ldiscs
> */
> @@ -230,4 +282,7 @@
> entry = create_proc_entry("tty/drivers", 0, NULL);
> if (entry)
> entry->proc_fops = &proc_tty_drivers_operations;
> + entry = create_proc_entry("tty/console", 0, NULL);
> + if (entry)
> + entry->proc_fops = &proc_tty_console_operations;
> }
---
~Randy
Randy Dunlap ([email protected]) said:
> > I'm not seriously proposing this. But, as far as I can tell, this
> > information isn't exposed to userspace anywhere, and it's a useful
> > thing to know. I'm certainly open for better ideas on how to expose
> > this (sysfs attributes? other?)
> >
> > ....
> >
> > The attached patch adds /proc/tty/console. The contents of it are
> > simply a description of the current drivers attached to /dev/console.
> > For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> > yield:
> >
> > # cat /proc/tty/console
> > unknown /dev/tty0
> > serial /dev/ttyS3
> >
>
> So it omits other consoles (non-tty) intentionally?
> or does it include them even though the procfs filename contains "tty"?
It only does consoles that have a tty_driver, as those are the ones I'd
find most interesting.
> Anyway, I'd like to see something like this.
> Compare http://www.xenotime.net/linux/patches/consoles-list.patch
> (April-2006).
Reading that, unless I'm missing something, you'd lose the device name
distinction (i.e., *which* serial port).
Bill
On Wed, 27 Feb 2008 13:52:25 -0500 Bill Nottingham wrote:
> Randy Dunlap ([email protected]) said:
> > > I'm not seriously proposing this. But, as far as I can tell, this
> > > information isn't exposed to userspace anywhere, and it's a useful
> > > thing to know. I'm certainly open for better ideas on how to expose
> > > this (sysfs attributes? other?)
> > >
> > > ....
> > >
> > > The attached patch adds /proc/tty/console. The contents of it are
> > > simply a description of the current drivers attached to /dev/console.
> > > For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> > > yield:
> > >
> > > # cat /proc/tty/console
> > > unknown /dev/tty0
> > > serial /dev/ttyS3
> > >
> >
> > So it omits other consoles (non-tty) intentionally?
> > or does it include them even though the procfs filename contains "tty"?
>
> It only does consoles that have a tty_driver, as those are the ones I'd
> find most interesting.
>
> > Anyway, I'd like to see something like this.
> > Compare http://www.xenotime.net/linux/patches/consoles-list.patch
> > (April-2006).
>
> Reading that, unless I'm missing something, you'd lose the device name
> distinction (i.e., *which* serial port).
I don't recall about that, but it would be Bad if correct.
I meant to list *all* consoles. I'm interested in netconsole,
console=lp0, console=ttyUSB0, etc., as well as serial port consoles.
Thanks.
---
~Randy
On Wed, 27 Feb 2008 13:18:57 -0500 Bill Nottingham <[email protected]> wrote:
> The attached patch adds /proc/tty/console. The contents of it are
> simply a description of the current drivers attached to /dev/console.
> For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> yield:
>
> # cat /proc/tty/console
> unknown /dev/tty0
> serial /dev/ttyS3
I must say that the what-consoles-are-registered problem makes my head spin
sometimes too. Seems a worthy objective.
However I think that a bunch of plain old printks which are emitted when a
console is added or removed would suffice?
We should display each console's CON_foo flags too.
Andrew Morton ([email protected]) said:
> > The attached patch adds /proc/tty/console. The contents of it are
> > simply a description of the current drivers attached to /dev/console.
> > For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> > yield:
> >
> > # cat /proc/tty/console
> > unknown /dev/tty0
> > serial /dev/ttyS3
>
> I must say that the what-consoles-are-registered problem makes my head spin
> sometimes too. Seems a worthy objective.
>
> However I think that a bunch of plain old printks which are emitted when a
> console is added or removed would suffice?
We already do that in register_console(), albeit without flags.
My concern is I'd like to easily programmatically do something with this
info - ideally it would be in sysfs so it can easily be used from udev
or something similar.
Bill
On Fri, 29 Feb 2008 10:07:30 -0500
Bill Nottingham <[email protected]> wrote:
> Andrew Morton ([email protected]) said:
> > > The attached patch adds /proc/tty/console. The contents of it are
> > > simply a description of the current drivers attached to /dev/console.
> > > For example, a boot with 'console=ttyS3,115200n1 console=tty0' would
> > > yield:
> > >
> > > # cat /proc/tty/console
> > > unknown /dev/tty0
> > > serial /dev/ttyS3
> >
> > I must say that the what-consoles-are-registered problem makes my head spin
> > sometimes too. Seems a worthy objective.
> >
> > However I think that a bunch of plain old printks which are emitted when a
> > console is added or removed would suffice?
>
> We already do that in register_console(), albeit without flags.
oh.
> My concern is I'd like to easily programmatically do something with this
> info - ideally it would be in sysfs so it can easily be used from udev
> or something similar.
That's the sort of information which really must be in the changelog, fully
spelled out.