diff options
author | Antonino A. Daplas <adaplas@gmail.com> | 2006-06-26 03:27:11 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-06-26 12:58:33 -0400 |
commit | 79062a0d396272f5b103d5223f3c96c58fd27451 (patch) | |
tree | 34cfb4e76422bfc3c3c089b4fdf6d3d502a32489 /Documentation | |
parent | 418d1ce61839251004fee6525f58a4581a75239e (diff) |
[PATCH] VT binding: Add new doc file describing the feature
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@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/console/console.txt | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt new file mode 100644 index 000000000000..4f3f28507761 --- /dev/null +++ b/Documentation/console/console.txt | |||
@@ -0,0 +1,127 @@ | |||
1 | Console Drivers | ||
2 | =============== | ||
3 | |||
4 | The linux kernel has 2 general types of console drivers. The first type is | ||
5 | assigned by the kernel to all the virtual consoles during the boot process. | ||
6 | This type will be called 'system driver', and only one system driver is allowed | ||
7 | to exist. The system driver is persistent and it can never be unloaded, though | ||
8 | it may become inactive. | ||
9 | |||
10 | The second type has to be explicitly loaded and unloaded. This will be called | ||
11 | 'modular driver' by this document. Multiple modular drivers can coexist at | ||
12 | any time with each driver sharing the console with other drivers including | ||
13 | the system driver. However, modular drivers cannot take over the console | ||
14 | that is currently occupied by another modular driver. (Exception: Drivers that | ||
15 | call take_over_console() will succeed in the takeover regardless of the type | ||
16 | of driver occupying the consoles.) They can only take over the console that is | ||
17 | occupied by the system driver. In the same token, if the modular driver is | ||
18 | released by the console, the system driver will take over. | ||
19 | |||
20 | Modular drivers, from the programmer's point of view, has to call: | ||
21 | |||
22 | take_over_console() - load and bind driver to console layer | ||
23 | give_up_console() - unbind and unload driver | ||
24 | |||
25 | In newer kernels, the following are also available: | ||
26 | |||
27 | register_con_driver() | ||
28 | unregister_con_driver() | ||
29 | |||
30 | If sysfs is enabled, the contents of /sys/class/tty/console/backend can be | ||
31 | examined. This shows the console drivers currently registered by the system. On | ||
32 | an x86 system with the framebuffer console enabled, the contents of this | ||
33 | attribute may be like this: | ||
34 | |||
35 | cat /sys/class/tty/console/backend | ||
36 | 0 S: VGA+ | ||
37 | 1 B: frame buffer device | ||
38 | |||
39 | The first line shows the VGA console driver, while the second line shows | ||
40 | the framebuffer console driver. | ||
41 | |||
42 | The leftmost numeric character is the driver ID. The middle character with | ||
43 | the colon describes the status of the driver. | ||
44 | |||
45 | S: - system driver (binding unspecified) | ||
46 | B: - bound modular driver | ||
47 | U: - unbound modular driver | ||
48 | |||
49 | The last column is the description of the driver. | ||
50 | |||
51 | Under /sys/class/tty/console are two other attributes, 'bind' and | ||
52 | 'unbind'. What does these 2 attributes do? As their name implies, echo'ing the | ||
53 | driver ID to 'bind' will bind an unbound modular driver, and to 'unbind' will | ||
54 | unbind a bound modular driver. Echo'ing the ID of a system driver to either | ||
55 | attribute will do nothing. | ||
56 | |||
57 | Thus: | ||
58 | |||
59 | echo 1 > /sys/class/tty/console/unbind | ||
60 | cat /sys/class/tty/console/backend | ||
61 | 0 S: VGA+ | ||
62 | 1 U: frame buffer device | ||
63 | |||
64 | When unbinding, the modular driver is detached first, and then the system | ||
65 | driver takes over the consoles vacated by the driver. Binding, on the other | ||
66 | hand, will bind the driver to the consoles that are currently occupied by a | ||
67 | system driver. | ||
68 | |||
69 | How useful is this feature? This is very useful for console driver | ||
70 | developers. By unbinding the driver from the console layer, one can unload the | ||
71 | driver, make changes, recompile, reload and rebind the driver without any need | ||
72 | for rebooting the kernel. For regular users who may want to switch from | ||
73 | framebuffer console to VGA console and vice versa, this feature also makes | ||
74 | this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb | ||
75 | for more details). | ||
76 | |||
77 | Notes for developers: | ||
78 | ===================== | ||
79 | |||
80 | take_over_console() is now broken up into: | ||
81 | |||
82 | register_con_driver() | ||
83 | bind_con_driver() - private function | ||
84 | |||
85 | give_up_console() is a wrapper to unregister_con_driver(), and a driver must | ||
86 | be fully unbound for this call to succeed. con_is_bound() will check if the | ||
87 | driver is bound or not. | ||
88 | |||
89 | Guidelines for console driver writers: | ||
90 | ===================================== | ||
91 | |||
92 | In order for binding to and unbinding from the console to properly work, | ||
93 | console drivers must follow these guidelines: | ||
94 | |||
95 | 1. All drivers, except system drivers, must call either register_con_driver() | ||
96 | or take_over_console(). register_con_driver() will just add the driver to | ||
97 | the console's internal list. It won't take over the | ||
98 | console. take_over_console(), as it name implies, will also take over (or | ||
99 | bind to) the console. | ||
100 | |||
101 | 2. All resources allocated during con->con_init() must be released in | ||
102 | con->con_deinit(). | ||
103 | |||
104 | 3. All resources allocated in con->con_startup() must be released when the | ||
105 | driver, which was previously bound, becomes unbound. The console layer | ||
106 | does not have a complementary call to con->con_startup() so it's up to the | ||
107 | driver to check when it's legal to release these resources. Calling | ||
108 | con_is_bound() in con->con_deinit() will help. If the call returned | ||
109 | false(), then it's safe to release the resources. This balance has to be | ||
110 | ensured because con->con_startup() can be called again when a request to | ||
111 | rebind the driver to the console arrives. | ||
112 | |||
113 | 4. Upon exit of the driver, ensure that the driver is totally unbound. If the | ||
114 | condition is satisfied, then the driver must call unregister_con_driver() | ||
115 | or give_up_console(). | ||
116 | |||
117 | 5. unregister_con_driver() can also be called on conditions which make it | ||
118 | impossible for the driver to service console requests. This can happen | ||
119 | with the framebuffer console that suddenly lost all of its drivers. | ||
120 | |||
121 | The current crop of console drivers should still work correctly, but binding | ||
122 | and unbinding them may cause problems. With minimal fixes, these drivers can | ||
123 | be made to work correctly. | ||
124 | |||
125 | ========================== | ||
126 | Antonino Daplas <adaplas@pol.net> | ||
127 | |||