tty idle time and hooking inode_ops from a chardev

[Phillip Susi]

I finally have spent some time figuring out an ancient bug that has 
bothered me on and off over the years: why the terminal idle time that 
who reports is sometimes very wrong.  It seems that this feature relies 
on the atime of the tty dev node being updated by the kernel whenever 
input is entered ( or more specifically, when it is read ).  Some 
programs, notably emacs and less, open /dev/tty rather than use stdin, 
and as a result, the atime of that inode is updated instead of the 
specific tty emacs is attached to.  This also means that if you mknod 
another inode to reach that tty ( say, for a chroot ), the times won't 
be updated correctly either.

To solve this, I think that a timestamp needs to be added to the struct 
tty_struct, and this should be updated whenever there is input, rather 
than updating the inode when the input is actually read.  In order to 
maintain compatibility with user space however, I would like to hook the 
stat calls and update the inode's atime from tty_struct whenever user 
space checks it.

To do this, I think that tty_open would need to replace the 
inode_operations pointer to point to its own version that has a set of 
functions that forward to the original inode_operations, but the 
iop->getattr would update the inode's atime from the tty_struct.  This 
means it needs to be able to locate both the tty_struct and the original 
inode_operations given the inode.  Is the i_private member of struct 
inode available for the tty code to use for this?

Alternatively, does anyone have a better idea to accomplish this?

Perhaps instead, struct cdev could gain a function pointer to allow it 
to hook vfs_stat?  I'm pretty sure there is a way to find the tty_struct 
given the cdev ( through dev_t? ), but I'm not sure what it is.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/