RFC: new /dev/tty* semantics

RFC: new /dev/tty* semantics

Post by ma.. » Thu, 25 Nov 1999 04:00:00



hi everybody!

accounting to new input and output devices, the possibility of more than
1 keyboard/mouse per logical terminal etc., we need other /dev/tty*
semantics.

my suggestion would be as following: (eg for tty1)

/dev/term01/audio01, mixer01
  same for audio02, if another sound input/output available.
/dev/term01/keyboard01, keyboard02, ...
  first,second,... keyboard (usb, at and ps/2 connector)
/dev/term01/bcr01
  barcode reader
/dev/term01/mouse01
  mouse devices
/dev/tty1
  symlink to /dev/term01/tty.
  combines the keyboard* as input channels

most of these devices could be symlinks to the existing /dev/audio01 and
so on.
OR the devices are moved in these directories.

if i want to use my ps/2 and an usb keyboard for one terminal, i could
make a link to /dev/usb/keyboardxxxx (or whatever).

programs will have fds 0,1,2 open on /dev/term*/tty

better ideas/suggestions?

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

RFC: new /dev/tty* semantics

Post by Etienne Lorrai » Thu, 25 Nov 1999 04:00:00



> better ideas/suggestions?

  Maybe have a look at devfs, a "virtual filesystem"
 for "/dev", a la "/proc".
 You will find hits on linux-kernel list.

  Etienne.

 
 
 

RFC: new /dev/tty* semantics

Post by ma.. » Sat, 27 Nov 1999 04:00:00


Quote:> > better ideas/suggestions?

>   Maybe have a look at devfs, a "virtual filesystem"
>  for "/dev", a la "/proc".
>  You will find hits on linux-kernel list.

I don't think about the actual device entries - they can be mknod()ed or
be made through devfs, I don't really care. But login, tty, (glibc?),
and so on could have to be upgraded - and as this is a lot of work, I'd
prefer to know a clean and proper way (that's lasting a long time)
before any of this work is done!

Phil

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

RFC: new /dev/tty* semantics

Post by Etienne Lorrai » Sat, 27 Nov 1999 04:00:00



> I don't think about the actual device entries - they can be mknod()ed or
> be made through devfs, I don't really care. But login, tty, (glibc?),
> and so on could have to be upgraded - and as this is a lot of work, I'd
> prefer to know a clean and proper way (that's lasting a long time)
> before any of this work is done!

  IHMO "login, tty, (glibc?)" do not have anywhere the path of your I/O
 device hardcoded - just the mknod numbers (defined by #include<>), so
 they do not need to be changed between very different Unixes.

 Usually on Unix, you do not care where is your device, like
 HD, tape backuper, sound card - on your PC or somewhere in
 your network (you know, the 3 PCs in front of you); you
 just have to setup your network as you like (the first PC
 will handle the keyboard because it is good at it, the second
 will handle the graphic card and display device, and you are
 working on the third one). The most amasing thing it that it
 _is used_ and works (complete remote control) - do you plan
 to change that ? and why ?

  Etienne.

 
 
 

RFC: new /dev/tty* semantics

Post by ma.. » Sat, 27 Nov 1999 04:00:00


Quote:>   IHMO "login, tty, (glibc?)" do not have anywhere the path of your
I/O
>  device hardcoded - just the mknod numbers (defined by #include<>), so
>  they do not need to be changed between very different Unixes.

>  Usually on Unix, you do not care where is your device, like
>  HD, tape backuper, sound card - on your PC or somewhere in
>  your network (you know, the 3 PCs in front of you); you
>  just have to setup your network as you like (the first PC
>  will handle the keyboard because it is good at it, the second
>  will handle the graphic card and display device, and you are
>  working on the third one). The most amasing thing it that it
>  _is used_ and works (complete remote control) - do you plan
>  to change that ? and why ?

sorry. I may have been not clear.

I think that login must be changed because the entire /dev/term* tree
needs to be chown()ed if someone logs in. And I think that there are
many other places where something like this could be happening.

As a move from /dev/tty* to /dev/term*/ makes some assumptions in a lot
of everybody's programs (eg shellscripts /dev/`tty`) wrong AND some
software (mostly  in the regions of kde, gnome, x11 ... graphical stuff
for the users) has to get updated too, this move must be stepped.

so 1st step: make /dev/term*/, populate it, and leave a link (or even
the device file) as /dev/tty*, and incrementally change the software.

BUT: as I said before, it is a lot of work - so I'd like comments before
anything gets done.

regards

phil

Sent via Deja.com http://www.deja.com/
Before you buy.

 
 
 

RFC: new /dev/tty* semantics

Post by Horst von Bra » Sun, 28 Nov 1999 04:00:00


[...]

Quote:>I think that login must be changed because the entire /dev/term* tree
>needs to be chown()ed if someone logs in. And I think that there are
>many other places where something like this could be happening.

Then all Unices from day one are horribly broken, and can't handle more than
one user at a time? Get a closer look at how things _really_ work.
--

Casilla 9G, Vi?a del Mar, Chile                               +56 32 672616
 
 
 

1. Semantics of /dev/tty

I've come across something weird and I'm attempting to work out
whether it is a Linux problem in it's handling of /dev/tty, or
whether it's a problem/feature of RZSZ.

I compiled Chuck Forseberg's rzsz ZModem package under Linux using
the sysvr3 entry, and it compiles up just fine under gcc 2.1 with
no modification whatever.  It even works if you use it to transfer
files over the same serial line on which you happen to be logged in.

I've used rzsz in the past under Sys V R3.x, on a Sun system, on
a Vax and on an SGI box without significant problems in the past.
This is, however, the first time I've used this particular release
so maybe it is peculiar to this version, but it has me wondering.
I used to be able to redirect stdin/stdout to a communications port
and conduct ZModem transfers with a remote system over a line on
which I WASN'T logged in (ie. a dialout session).  Simply doing:

  rz </dev/ttyXX >/dev/ttyXX

would do this just fine.

However, under Linux (0.95a) and this particular release it doesn't
work. Inspecting the code in rbsb.c, I find that all transfer I/O
takes place via "/dev/tty", which is explicitly opened and assigned
to "int Tty" and "FILE *Ttystream" respectively.

Is it Linux that doesn't do this correctly?  Do the semantics of
/dev/tty under UNIX mean that it's handles access the console or
are they supposed to be redirected where stdin/stdout point (and
therefore this is a bug in Linux)?

Unfortunately, I haven't done much kernel hacking in the past and
don't have ready access to the appropriate documentation, nor do
I have another UNIX system handy right now to test the theory,
but I suspect that it's a Linux bug.

Could someone please let me know what the "correct" behaviour of
/dev/tty should be when stdin/stdout have been redirected?

Thanks,

  david

..............................................................................
david nugent          Public Access Usenet        "Only Nixon can go to China"


PO Box 260, Endeavour Hills, Victoria, Australia, 3802.

2. Chooing a shell

3. Getting the real tty device name (/dev/tty not good enough)

4. Date is missing slashes

5. Inconsistant semantics between select() on pipe and tty

6. Notification when network becomes available?

7. /dev/ttyS? vs /dev/cua?

8. nVidia server?

9. diff between /dev/tty and /dev/pts

10. /dev/cua /dev/ttyS and getty_ps

11. /dev//dev/tty: No such file or directory when requesting uptime

12. syslogd: "/" in "/dev//dev/tty"