Look up the device from its tty file

I'm not sure exactly how the device nodes are created (i.e. the exact sequence of events that lead to their creation), but I'm pretty sure the kernel creates the underlying devices for the 63 /dev/ttyN devices (plus /dev/tty) internally, and udev does the work of making them available inside /dev (except for /dev/tty and /dev/tty1 which are created by /etc/init.d/udev-mount with mknod).

I don't think you can limit the number of kernel devices via configuration.

Here is a workaround if you want to limit the number of devices that appear in your /dev though. Create a /etc/udev/rules.d/99-my-tty-rules.rules file and put something like the following in it:

KERNEL=="tty[2-9][0-9]", RUN="/bin/rm /dev/%k", OPTIONS+="ignore_device"

This will get rid of tty device files numbered 20 and above.

Notes:

• Using rm in there looks really strange, but I can't find a way to not create the node in the first place
• Playing with these entries a bit too enthusiastically can lead to interesting problems - use with caution.

TTYs are files that you can use just like any other. You can open them with the standard file-opening tools of your language and read or write from them. They have some special behaviour that's different to "ordinary" files, but the basics are the same. I'll cover some of the special cases at the end, but first, an experiment.

One interesting thing you can do straight from a regular terminal. Run tty and it will print a line like:

/dev/pts/2

That's the TTY device your terminal is running in. You can write something to that terminal:

$ echo Hello > /dev/pts/2
Hello
$

You can even read from it:

$ read X < /dev/pts/2
hello
$ echo $X
hello
$

(read X is sh's "read a line from standard input into variable X" command; the < is to use /dev/pts/2 as standard input for the read command; the first "hello" I typed, and the second was printed out).

If you open up another shell, say by using screen or xterm, you can run run echo spooky > /dev/pts/2 in that shell to make the text appear on your original terminal, and the same for the other commands. All of this is just your shell opening a file without knowing it's a TTY.

Here is a very simple C program that does just what you asked, and writes a single character to /dev/pts/3, then reads a single byte back from it:

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>    
int main() {
    char byte;
    int fd = open("/dev/pts/3", O_RDWR);
    write(fd, "X", 1);
    ssize_t size = read(fd, &byte, 1);
    printf("Read byte %c\n", byte);
    return 0;
}

A real TTY device that's attached to a shell or terminal emulator will have interesting behaviour there, but you should get something back.

To access a terminal you need to have permission to use it. Those are just the standard file permissions you see with ls -l and set with chmod: you need read permission to open the file and read it, and write permission to write into it. The TTYs that back your terminal will be owned by you, but another user's TTY won't, and TTYs for USB devices may or may not be, depending on your configuration. You can change the permissions in the same way as always.

As far as writing a program to work with it goes, you don't need to do much special. You can see in the example that one thing you don't need to do is close the file every time to have your data read by the other end: the TTY files act like pipelines, just pushing data in both directions as it comes in. When I wrote text to the TTY it appeared immediately, and when I read from it afterwards there wasn't anything waiting for me already. It's not like writing to a regular file where the data gets saved on disk - it gets passed on immediately to the other side, or stored in memory until someone reads it.

You may want to use the select function so that you can do other things while you wait for the device to say something, but if you're happy to just wait for data to come through you can just use blocking reads and let the OS do the lifting.

One thing to keep in mind is that there is can be limited buffer size in the kernel, and if you write a lot of data at once you may end up blocking without meaning to. If that's likely to be a problem, use non-blocking IO with open("/dev/...", O_RDWR | O_NONBLOCK). The principle will be the same either way.