The patch titled
VT binding: Add new doc file describing the feature
has been added to the -mm tree. Its filename is
vt-binding-add-new-doc-file-describing-the-feature.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: VT binding: Add new doc file describing the feature
From: "Antonino A. Daplas" <adaplas@xxxxxxxxx>
This newly added file will:
- Describe the characteristics of 2 general types of console drivers
- How to use the sysfs to unbind and bind console drivers
- Uses for this feature
Signed-off-by: Antonino Daplas <adaplas@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
---
Documentation/console/console.txt | 127 ++++++++++++++++++++++++++++
1 file changed, 127 insertions(+)
diff -puN /dev/null Documentation/console/console.txt
--- /dev/null 2006-06-03 22:34:36.282200750 -0700
+++ devel-akpm/Documentation/console/console.txt 2006-06-09 01:56:20.000000000 -0700
@@ -0,0 +1,127 @@
+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 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, has to call:
+
+ take_over_console() - load and bind driver to console layer
+ give_up_console() - unbind and unload driver
+
+In newer kernels, the following are also available:
+
+ register_con_driver()
+ unregister_con_driver()
+
+If sysfs is enabled, the contents of /sys/class/tty/console/backend can be
+examined. This shows the console drivers currently registered by the system. On
+an x86 system with the framebuffer console enabled, the contents of this
+attribute may be like this:
+
+cat /sys/class/tty/console/backend
+0 S: VGA+
+1 B: frame buffer device
+
+The first line shows the VGA console driver, while the second line shows
+the framebuffer console driver.
+
+The leftmost numeric character is the driver ID. The middle character with
+the colon describes the status of the driver.
+
+ S: - system driver (binding unspecified)
+ B: - bound modular driver
+ U: - unbound modular driver
+
+The last column is the description of the driver.
+
+Under /sys/class/tty/console are two other attributes, 'bind' and
+'unbind'. What does these 2 attributes do? As their name implies, echo'ing the
+driver ID to 'bind' will bind an unbound modular driver, and to 'unbind' will
+unbind a bound modular driver. Echo'ing the ID of a system driver to either
+attribute will do nothing.
+
+Thus:
+
+echo 1 > /sys/class/tty/console/unbind
+cat /sys/class/tty/console/backend
+0 S: VGA+
+1 U: frame buffer device
+
+When unbinding, the modular driver is detached first, and then the system
+driver takes over the consoles vacated by the driver. Binding, on the other
+hand, will bind the driver to the consoles that are currently occupied by a
+system driver.
+
+How useful is this feature? This is very useful for console driver
+developers. By unbinding the driver from the console layer, one can unload the
+driver, make changes, recompile, reload and rebind the driver without any need
+for rebooting the kernel. For regular users who may want to switch from
+framebuffer console to VGA console and vice versa, this feature also makes
+this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
+for more details).
+
+Notes for developers:
+=====================
+
+take_over_console() is now broken up into:
+
+ register_con_driver()
+ bind_con_driver() - private function
+
+give_up_console() is a wrapper to unregister_con_driver(), and a driver must
+be fully unbound for this call to succeed. con_is_bound() will check if the
+driver is bound or not.
+
+Guidelines for console driver writers:
+=====================================
+
+In order for binding to and unbinding from the console to properly work,
+console drivers must follow these guidelines:
+
+1. All drivers, except system drivers, must call either register_con_driver()
+ or take_over_console(). register_con_driver() will just add the driver to
+ the console's internal list. It won't take over the
+ console. take_over_console(), as it name implies, will also take over (or
+ bind to) the console.
+
+2. All resources allocated during con->con_init() must be released in
+ con->con_deinit().
+
+3. All resources allocated in con->con_startup() must be released when the
+ driver, which was previously bound, becomes unbound. The console layer
+ does not have a complementary call to con->con_startup() so it's up to the
+ driver to check when it's legal to release these resources. Calling
+ con_is_bound() in con->con_deinit() will help. If the call returned
+ false(), then it's safe to release the resources. This balance has to be
+ ensured because con->con_startup() can be called again when a request to
+ rebind the driver to the console arrives.
+
+4. Upon exit of the driver, ensure that the driver is totally unbound. If the
+ condition is satisfied, then the driver must call unregister_con_driver()
+ or give_up_console().
+
+5. unregister_con_driver() can also be called on conditions which make it
+ impossible for the driver to service console requests. This can happen
+ with the framebuffer console that suddenly lost all of its drivers.
+
+The current crop of console drivers should still work correctly, but binding
+and unbinding them may cause problems. With minimal fixes, these drivers can
+be made to work correctly.
+
+==========================
+Antonino Daplas <adaplas@xxxxxxx>
+
_
Patches currently in -mm which might be from adaplas@xxxxxxxxx are
git-intelfb.patch
savagefb-allocate-space-for-current-and-saved-register.patch
savagefb-add-state-save-and_restore-hooks.patch
savagefb-add-state-save-and_restore-hooks-fix.patch
fbdev-more-accurate-sync-range-extrapolation.patch
nvidiafb-revise-pci_device_id-table.patch
atyfb-fix-hardware-cursor-handling.patch
atyfb-remove-unneeded-calls-to-wait_for_idle.patch
atyfb-set-correct-acceleration-flags.patch
epson1355fb-update-platform-code.patch
vesafb-update-platform-code.patch
vfb-update-platform-code.patch
vga16fb-update-platform-code.patch
fbdev-static-pseudocolor-with-depth-less-than-4-does.patch
savagefb-whitespace-cleanup.patch
fbdev-firmware-edid-fixes.patch
nvidiafb-add-support-for-geforce-6100-and-related-chipsets.patch
vesafb-fix-return-code-of-vesafb_setcolreg.patch
vesafb-prefer-vga-registers-over-pmi.patch
atyfb-fix-dead-code.patch
fbdev-coverity-bug-85.patch
fbdev-coverity-bug-90.patch
backlight-fix-kconfig-dependency.patch
detaching-fbcon-fix-vgacon-to-allow-retaking-of-the.patch
detaching-fbcon-fix-give_up_console.patch
detaching-fbcon-remove-calls-to-pci_disable_device.patch
detaching-fbcon-add-sysfs-class-device-entry-for-fbcon.patch
detaching-fbcon-clean-up-exit-code.patch
detaching-fbcon-add-capability-to-attach-detach-fbcon.patch
detaching-fbcon-update-documentation.patch
vt-binding-add-binding-unbinding-support-for-the-vt.patch
vt-binding-add-sysfs-support.patch
vt-binding-update-fbcon-to-support-binding.patch
vt-binding-fbcon-update-documentation.patch
vt-binding-add-new-doc-file-describing-the-feature.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
