# kernel virtual terminals

Operating systems provide a range of devices that are kernel virtual terminals. Unlike a user-space virtual terminal, where the terminal emulator program is running as a service, with kernel virtual terminals the terminal emulator program is running inside the kernel.

- Linux systems provide kernel virtual terminals on `/dev/tty1` to `/dev/tty63`. See the linux-vt(4) manual page for details.

- FreeBSD systems provide kernel virtual terminals on devices `/dev/ttyv0` to `/dev/ttyv8`. See the vt(4) and syscons(4) manual pages for details.

- OpenBSD systems provide kernel virtual terminals on devices `/dev/ttyC0` to `/dev/ttyCb`. See the wscons(4) manual page for details.

- NetBSD systems provide kernel virtual terminals on devices `/dev/ttyE0` to `/dev/ttyEb`.

Login on such terminals is done with `ttylogin` services configured to use those devices of course, which can be managed just like other ordinary services. There is one augmentation to ordinary service management: the `preset` command uses the ordinary preset file mechanism, but can also read the `/etc/ttys` file.

## Containers should use user-space virtual terminals

In containers, access to the real kernel virtual terminal devices is often prevented by the containerization system, which restricts access to the system's character devices from within the container. One container convention is to symbolically link the kernel virtual terminal device names to the front ends of pseudo-terminals which the containerization system sets up; `/dev/tty1` being a symbolic link to (say) `/dev/pts/2` which is the front end of a pseudo-terminal allocated by the containerization system. Another is to still have the containerization system set up pseudo-terminals, and tell the contained system about them through a `container_ttys` environment variable. Both of these are clumsy and quite unnecessary with the nosh toolset.

With the nosh toolset, do not have the containerization system involved at all. Simply use user-space virtual terminals.

## Linux tools for `ttylogin` service management on demand

Enabled `ttylogin@` services are started at bootstrap in the ordinary way, as they are `wanted-by/` the `multi-user` target.

However, on Linux such services can be left disabled and instead can be activated on demand by the `ttylogin-starter` tool. This utility, for which there is a service bundle allowing one to run it itself as a service, starts `ttylogin` services, directly, as and when the user switches between kernel virtual terminals.

## Leaving room for X or console-fb-realizer

An X server needs a virtual terminal allocated to it for the same reason that `console-kvt-realizer` does: interlocking the use of the framebuffer and input event subsystem with the kernel's terminal emulator program. So if using kernel virtual terminals alongside an X server, either one starts the server directly from a login session on one of those terminals, or one reserves a virtual terminal for the X server.

To do this, one simply disables the service. (Note that `ttylogin-starter`, which manually starts services irrespective of their enable/disable state, is incompatible with X servers and `console-kvt-realizer` and should not be used when they are.) There are three ways to do this:

- With presets:

  - If the `/etc/ttys` file is being used for presets, one first presets the service off in that file.

    >     ttyv7 /usr/bin/false teken off secure

    Then one uses the external formats conversion mechanism to import that preset.

  - One writes an ordinary preset with (for example) lines in `/etc/system-control/presets/60-ttys.preset` saying:

    >     disable ttylogin@ttyv7

    Then one applies the preset:

    >     system-control preset ttylogin@ttyv7

- Directly, disabling the service in the usual way:

  >     system-control disable ttylogin@ttyv7

  This will be overridden should presets be applied across `ttylogin@` services, which happens when installing/upgrading some nosh packages.