[PULL] Docs: console.txt: A complete overhaul

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The following changes:

  Docs: console.txt: A complete overhaul

since commit 9e79e3e9dd9672b37ac9412e9a926714306551fe:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc
  (2011-08-30 11:28:18 -0700)

are available in the git repository at:

  git://github.com/mfwitten/linux.git docs/console

For various reasons, I didn't produce a fine-grained patch series;
there is just this blob of new text, which renders the diff somewhat
useless.

Consequently, I present in the following the full text of the
refurbished Documentation/console/console.txt (fortunately, it's not
terribly long):

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

The linux kernel has 2 general types of console driver.

  System driver
  -------------
  The driver of this type is bound to all virtual consoles during the boot
  process.  Only one system driver is allowed to be registered; the system
  driver is persistent and it may never be unregistered, though it may become
  unbound from any virtual console.

  Modular driver
  --------------
  A driver of this type must be explicitly registered, bound, unbound, and
  unregistered.

  NOTE: The ability to bind and unbind a modular driver must be enabled
  when configuring the kernel:

    Device Drivers
      |
      +-> Character devices
            |
            +-> Support for binding and unbinding console drivers

Binding and Unbinding
=====================

Multiple drivers may be simultaneously registered with the virtual terminal
layer.  However, only one driver may be bound to a particular virtual console
at a given time, as described by the following rules:

  * When no driver is bound to a particular virtual console, then the system
    driver is automatically bound to it.

  * When the system driver is bound to a particular virtual console, then
    binding a modular driver to that virtual console automatically unbinds
    the system driver first, thereby allowing the modular driver to be bound
    to it.

  * Usually, it is necessary to unbind one modular driver before binding
    another modular driver to the same virtual console.

  * If a driver is bound to any virtual console that is in KD_GRAPHICS mode,
    then binding and unbinding that driver will not succeed; the X Window
    System is an example of an application that sets the console to
    KD_GRAPHICS mode.

The ability to register, bind, unbind, and unregister a console driver is
mainly useful to developers; a driver in development could be unbound from
the virtual console(s), unregistered, rebuilt from source, reregistered,
and rebound to the virtual console(s) without any need for rebooting the
kernel.  Of course, end users may use this feature e.g. to switch between a
framebuffer console driver and a VGA console driver (please read fbcon.txt
under Documentation/fb for more details).

The sysfs Interface
===================

It is intended that modern drivers may only be bound to the virtual console(s)
and unbound through a sysfs interface.

When sysfs is enabled, the directory /sys/class/vtconsole/ contains one
subdirectory for each registered console driver; these subdirectories are
named vtcon<n>, where <n> is an integer from 0 to 15.  Thus:

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

Each such subdirectory has at least 3 noteworthy files:

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

Specifically:

  bind (read/write)
  -----------------
  It shows the status of the driver when read, or acts to bind or unbind the
  driver to the virtual console(s) when written to.  The possible values are:

    0: When read, it means the driver is unbound from all virtual consoles.
       When written, it commands the virtual terminal layer to unbind the
       driver from all virtual consoles to which it is bound.

    1: When read, it means the driver is bound to at least one virtual
       console.  When written, it commands the virtual terminal layer
       to attempt to bind the driver to some predetermined range of virtual
       consoles; ultimately, the driver is only bound to those virtual
       consoles for which binding is allowed, as per the aformentioned rules.

  name (read-only)
  ----------------
  It shows the name of the driver, using this format:

    (<type>) <name>

  where <type> may be 'S' for 'system driver' or 'M' for 'modular driver',
  and <name> may be some arbitrary string.  For example:

    $ cat /sys/class/vtconsole/vtcon0/name
    (S) VGA+
    $ cat /sys/class/vtconsole/vtcon1/name
    (M) frame buffer device

  uevent
  ------
  Ignore this file.

Notes for Developers
====================

Traditionally, a modular driver is set up and torn down with the following
functions:

  * take_over_console() /* Register and forcibly bind the driver. */
  * give_up_console()   /* Unregister the driver. */

For backwards compatibility, a call to the function take_over_console() first
automatically unbinds any (possibly modular) driver that is currently bound to
the conflicting virtual console(s), and then binds the provided console driver
to the virtual console(s) in question; this is the only public interface
outside of sysfs for controlling the binding and unbinding of drivers.

In order for give_up_console() to succeed, the provided driver must be unbound
from all virtual consoles; con_is_bound() may be used to determine whether
the provided driver is bound to any virtual console.

With newer kernels, a driver should only be registered and unregistered with
the following (leaving binding and unbinding to the sysfs interface):

  * register_con_driver()   /* Register the driver. */
  * unregister_con_driver() /* Unregister the driver. */

In fact, give_up_console() is an alias for unregister_con_driver(), and
take_over_console() is now implemented with calls to:

  * register_con_driver()
  * bind_con_driver()     /* This is a private function. */

In order for binding and unbinding to work properly, console drivers must
follow these guidelines:

  * All modular drivers must call either register_con_driver() or
    take_over_console().

  * All resources allocated by con->con_init() must be release by
    con->con_deinit().

  * All resources allocated by con->con_startup() must be released
    when the driver is unbound from all virtual consoles after having
    been previously bound to at least one virtual console.

    This balance must be ensured because con->con_startup() might be
    called again when another request arrives to bind the driver to a
    virtual console once more.

    Unlike con->con_init(), there is no complement to con->con_startup()
    for the explicit purpose of such releasing; consequently, it's up
    to the driver to check when it may do so safely. For instance, a
    driver may call con_is_bound() in con->con_deinit(), releasing the
    resources if the result is false.

  * Before exiting, a driver must ensure that it is unregistered
    via a call to either unregister_con_driver() or give_up_console();
    note that these calls to these functions only succeed if the driver
    is already unbound from all virtual consoles.

  * unregister_con_driver() may also be called under any condition
    that makes it impossible for the driver to service console requests.

Older console drivers should still work correctly, but binding and unbinding
them may cause problems.  With minimal fixes, these drivers could be made to
work correctly.

==========================
Originally written by Antonino Daplas <adaplas@xxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux