lkml.org 
[lkml]   [2000]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TIOCGDEV ioctl
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 <garloff@suse.de> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE GmbH, Nuernberg, FRG SCSI, Security
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.842 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site