Hi Linus, Alan,
some applications do need to know where the console (/dev/console)
actually maps to. For processes with a controlling terminal, you may see
it in /proc/$$/stat. However, daemons are supposed to run detached (they
don't want to get killed by ^C) and some processes like init or bootlogd
do still need to be able to find out.
The kernel provides this information -- sort of:
It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
it changes between different kernel archs and revisions, so using it is
an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
sysvinit sources. Shudder!
Having a new ioctl, just returning the device no is a much cleaner solution,
IMHO. So, I created the TIOCGDEV, which Miquel suggests in his sysvinit
sources. It makes querying the actual console device as easy as
int tty; ioctl (0, TIOCGDEV, &tty);
Patches against 2.2.18 and 2.4.0-testX are attached.
Please apply.
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
On Sat, 16 Dec 2000, Kurt Garloff wrote:
>
> The kernel provides this information -- sort of:
> It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
> it changes between different kernel archs and revisions, so using it is
> an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
> sysvinit sources. Shudder!
Please instead do the same thing /dev/tty does, namely a sane interface
that shows it as a symlink in /proc (or even in /dev)
Linus
> Hi Linus, Alan,
>
> some applications do need to know where the console (/dev/console)
> actually maps to. For processes with a controlling terminal, you may see
> it in /proc/$$/stat. However, daemons are supposed to run detached (they
> don't want to get killed by ^C) and some processes like init or bootlogd
> do still need to be able to find out.
>
> The kernel provides this information -- sort of:
> It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
> it changes between different kernel archs and revisions, so using it is
> an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
> sysvinit sources. Shudder!
>
> Having a new ioctl, just returning the device no is a much cleaner solution,
> IMHO. So, I created the TIOCGDEV, which Miquel suggests in his sysvinit
> sources. It makes querying the actual console device as easy as
> int tty; ioctl (0, TIOCGDEV, &tty);
>
> Patches against 2.2.18 and 2.4.0-testX are attached.
> Please apply.
Based on fgconsole.c. I just threw it together in a few minutes.
/*
* consolewhat.c - Prints which VC /dev/console is.
*/
#include <sys/ioctl.h>
#include <linux/vt.h>
int
main(){
struct vt_stat vtstat;
int fd;
fd = open("/dev/console", O_RDONLY);
if (fd < 0 && errno == EACCES)
fd = open("/dev/console", O_WRONLY);
if (fd < 0)
return -1;
if (ioctl(fd, VT_GETSTATE, &vtstat)) {
perror("consolewhat: VT_GETSTATE");
exit(1);
}
printf("%d\n", vtstat.v_active);
return 0;
}
On Fri, 15 Dec 2000, Linus Torvalds wrote:
> Please instead do the same thing /dev/tty does, namely a sane interface
> that shows it as a symlink in /proc (or even in /dev)
There you go... (/proc/tty/console -> /dev/tty<current_VC>; may very well
be dangling, but then you have a current VC even if your /dev consists
of /dev/console and nothing else, so there's nothing to do about that;
doesn't handle TIOCCONS redirects, but IMO that should be a separate
object anyway).
Cheers,
Al
diff -urN rc12-pre8/fs/proc/proc_tty.c rc12-pre8-tty/fs/proc/proc_tty.c
--- rc12-pre8/fs/proc/proc_tty.c Sat Apr 22 02:35:31 2000
+++ rc12-pre8-tty/fs/proc/proc_tty.c Sat Dec 16 00:14:20 2000
@@ -166,6 +166,26 @@
driver->proc_entry = 0;
}
+extern int fg_console;
+static int proc_cons_readlink(struct dentry *dentry, char *buffer, int buflen)
+{
+ char tmp[30];
+ sprintf(tmp, "/dev/tty%d", fg_console);
+ return vfs_readlink(dentry,buffer,buflen,tmp);
+}
+
+static int proc_cons_follow_link(struct dentry *dentry, struct nameidata *nd)
+{
+ char tmp[30];
+ sprintf(tmp, "/dev/tty%d", fg_console);
+ return vfs_follow_link(nd,tmp);
+}
+
+static struct inode_operations proc_cons_operations = {
+ readlink: proc_cons_readlink,
+ follow_link: proc_cons_follow_link,
+};
+
/*
* Called by proc_root_init() to initialize the /proc/tty subtree
*/
@@ -175,6 +195,9 @@
return;
proc_tty_ldisc = proc_mkdir("tty/ldisc", 0);
proc_tty_driver = proc_mkdir("tty/driver", 0);
+
+ proc_tty_console = create_proc_entry("tty/console", S_IFLNK|0777, NULL);
+ proc_tty_console->proc_iops = &proc_console_ops;
create_proc_read_entry("tty/ldiscs", 0, 0, tty_ldiscs_read_proc,NULL);
create_proc_read_entry("tty/drivers", 0, 0, tty_drivers_read_proc,NULL);
According to Alexander Viro:
> On Fri, 15 Dec 2000, Linus Torvalds wrote:
>
> > Please instead do the same thing /dev/tty does, namely a sane interface
> > that shows it as a symlink in /proc (or even in /dev)
>
> There you go... (/proc/tty/console -> /dev/tty<current_VC>; may very well
The current VT (fg_console) and /dev/console are 2 different things ...
/dev/console might be /dev/ttyS1. Besides to get at fg_console
we already have ioctl(/dev/tty0, TIOCLINUX, 12)
There is currently no way to find out with what device /dev/console
is associated.
Why is that needed? For example, I wrote a program 'bootlogd' that opens
/dev/console and a pty pair, uses TIOCCONS to redirect console
messages to the pty pair so they can be logged. However one would
like to write those messages to the _actual_ console as well, but
there is no way to find out what the real console is.
For this application a ioctl is better than a /proc symlink since
it would be started before /proc is even mounted.
Mike.
--
RAND USR 16514
In article <[email protected]>,
James Simmons <[email protected]> wrote:
>Based on fgconsole.c. I just threw it together in a few minutes.
>/*
> * consolewhat.c - Prints which VC /dev/console is.
> */
You're confusing /dev/console and /dev/tty0. /dev/console might be
associated with /dev/ttyS0 or /dev/lp1
Mike.
--
RAND USR 16514
On Sat, 16 Dec 2000, Miquel van Smoorenburg wrote:
> There is currently no way to find out with what device /dev/console
> is associated.
>
> Why is that needed? For example, I wrote a program 'bootlogd' that opens
> /dev/console and a pty pair, uses TIOCCONS to redirect console
> messages to the pty pair so they can be logged. However one would
> like to write those messages to the _actual_ console as well, but
> there is no way to find out what the real console is.
>
> For this application a ioctl is better than a /proc symlink since
> it would be started before /proc is even mounted.
So mount it... It's not like you didn't have enough privileges for that,
after all, and mount("proc", "/proc", "proc", 0, 0); doesn't look too
complex.
OK, I can see the point of finding out where the console is redirected
to. How about the following:
/proc/sys/vc -> /dev/tty<n>
/proc/sys/console -> where the hell did we redirect it or
vc if there's no redirect right now
Will that be OK with you?
According to Alexander Viro:
> OK, I can see the point of finding out where the console is redirected
> to. How about the following:
>
> /proc/sys/vc -> /dev/tty<n>
> /proc/sys/console -> where the hell did we redirect it or
> vc if there's no redirect right now
> Will that be OK with you?
Well, I'd prefer the ioctl, but I can see the general direction the
kernel is heading to: get rid of numeric ioctls and sysctl()s and
put all that info under /proc.
However /proc/sys only contains directories now, it would look
kindof ugly to put 2 symlinks in there directly. Oh well.
Mike.
--
RAND USR 16514
On Sat, 16 Dec 2000, Miquel van Smoorenburg wrote:
> According to Alexander Viro:
> > OK, I can see the point of finding out where the console is redirected
> > to. How about the following:
> >
> > /proc/sys/vc -> /dev/tty<n>
> > /proc/sys/console -> where the hell did we redirect it or
> > vc if there's no redirect right now
> > Will that be OK with you?
>
> Well, I'd prefer the ioctl, but I can see the general direction the
> kernel is heading to: get rid of numeric ioctls and sysctl()s and
> put all that info under /proc.
>
> However /proc/sys only contains directories now, it would look
Huh? Oh, sorry. /proc/tty, indeed - it was a braino. BTW, I think
that a mini-fs with a device node for each registered console +
symlink (say it, "default") pointing to the default one might make
sense too. Comments?
> You're confusing /dev/console and /dev/tty0. /dev/console might be
> associated with /dev/ttyS0 or /dev/lp1
Oops. Forgot about serial consoles :-(
On Sat, Dec 16, 2000 at 06:57:20AM -0500, Alexander Viro wrote:
> On Sat, 16 Dec 2000, Miquel van Smoorenburg wrote:
> > According to Alexander Viro:
> > > OK, I can see the point of finding out where the console is redirected
> > > to. How about the following:
> > >
> > > /proc/sys/vc -> /dev/tty<n>
> > > /proc/sys/console -> where the hell did we redirect it or
> > > vc if there's no redirect right now
> > > Will that be OK with you?
> >
> > Well, I'd prefer the ioctl, but I can see the general direction the
> > kernel is heading to: get rid of numeric ioctls and sysctl()s and
> > put all that info under /proc.
Yes; it looks nicer not to grow the number of ioctls more and more,
but to make things more visible in /proc.
On the other hand, there are some advantages of the ioctl:
It's fast, easy and does not need /proc. That cab be of relevance
for embedded devices, e.g., where ram is short.
> Huh? Oh, sorry. /proc/tty, indeed - it was a braino. BTW, I think
> that a mini-fs with a device node for each registered console +
> symlink (say it, "default") pointing to the default one might make
> sense too. Comments?
Yes, looks like a good solution to me.
But that's far more complicated than the ioctl.
Looking at the sources and starting to write some code, it's not so obvious
to me how to get the right device no all the time and how to create the
correct symlink also in 2.2. Yes, it needs to work on both 2.2 and 2.4
kernels.
So, I'd like to ask for inclusion of the original patch.
Or can we come up with the /proc/tty solution without adding too much code?
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
On Fri, Dec 15, 2000 at 05:11:07PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 16 Dec 2000, Kurt Garloff wrote:
> >
> > The kernel provides this information -- sort of:
> > It contains the TIOCTTYGSTRUCT syscall which returns a struct. Of course,
> > it changes between different kernel archs and revisions, so using it is
> > an ugly hack. Grab for TIOCTTYGSTRUCT_HACK in the bootlogd.c file of the
> > sysvinit sources. Shudder!
>
> Please instead do the same thing /dev/tty does, namely a sane interface
> that shows it as a symlink in /proc (or even in /dev)
Not a symlink but this is what is needed: if fd 0 of the current task is a
tty then give the hash of the tty. I'm using fd 0 because current->tty may
not be set for spawned tasks of init.
I've attached two patches, one for 2.4 and one for 2.2. They're rather
simple, therefore one may use this for setting a link.
Werner
BTW: I'm missing a real replacement for my sys_revoke() patch done at the
end of October. Al Viro has wipe it out but never shows an alternative way
of implementing such a beast.