Documentation/driver-api/console.rst

Source file repositories/reference/linux-study-clean/Documentation/driver-api/console.rst

File Facts

System
Linux kernel
Corpus path
Documentation/driver-api/console.rst
Extension
.rst
Size
5972 bytes
Lines
153
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

===============
Console Drivers
===============

The Linux kernel has 2 general types of console drivers.  The first type is
assigned by the kernel to all the virtual consoles during the boot process.
This type will be called 'system driver', and only one system driver is allowed
to exist. The system driver is persistent and it can never be unloaded, though
it may become inactive.

The second type has to be explicitly loaded and unloaded. This will be called
'modular driver' by this document. Multiple modular drivers can coexist at
any time with each driver sharing the console with other drivers including
the system driver. However, modular drivers cannot take over the console
that is currently occupied by another modular driver. (Exception: Drivers that
call do_take_over_console() will succeed in the takeover regardless of the type
of driver occupying the consoles.) They can only take over the console that is
occupied by the system driver. In the same token, if the modular driver is
released by the console, the system driver will take over.

Modular drivers, from the programmer's point of view, have to call::

	 do_take_over_console() - load and bind driver to console layer
	 give_up_console() - unload driver; it will only work if driver
			     is fully unbound

In newer kernels, the following are also available::

	 do_register_con_driver()
	 do_unregister_con_driver()

If sysfs is enabled, the contents of /sys/class/vtconsole can be
examined. This shows the console backends currently registered by the
system which are named vtcon<n> where <n> is an integer from 0 to 15.
Thus::

       ls /sys/class/vtconsole
       .  ..  vtcon0  vtcon1

Each directory in /sys/class/vtconsole has 3 files::

     ls /sys/class/vtconsole/vtcon0
     .  ..  bind  name  uevent

What do these files signify?

     1. bind - this is a read/write file. It shows the status of the driver if
        read, or acts to bind or unbind the driver to the virtual consoles
        when written to. The possible values are:

	0
	  - means the driver is not bound and if echo'ed, commands the driver
	    to unbind

        1
	  - means the driver is bound and if echo'ed, commands the driver to
	    bind

     2. name - read-only file. Shows the name of the driver in this format::

	  cat /sys/class/vtconsole/vtcon0/name
	  (S) VGA+

	      '(S)' stands for a (S)ystem driver, i.e., it cannot be directly
	      commanded to bind or unbind

	      'VGA+' is the name of the driver

Annotation

Implementation Notes