Documentation-console-console

Chinese translated version of Documentation-console-console


If you have any comment or update to the content, please contact the
original document maintainer directly.  However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help.  Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.


Chinese maintainer:  <steven910812@gmail.com>
---------------------------------------------------------------------
Documentation-console-console的中文翻译


如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。


中文版维护者： 徐唯  <steven910812@gmail.com>
中文版翻译者： 徐唯  <steven910812@gmail.com>
中文版校译者： 徐唯  <steven910812@gmail.com>


以下为正文
---------------------------------------------------------------------




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.


Linux内核有2种一般类型的控制台驱动程序。
第一种类型是内核在引导过程中的所有的虚拟控制台分配。
这种类型被称为“系统驱动”，只允许一个系统驱动存在。
系统驱动程序是永久性的，它不能被卸载，但它可能会变为无效。


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.


第二种类型必须通过显式加载和卸载。这被称为“模块化驱动“。
多个模块化驱动器可以在任何时间与每个驱动程序与其他驱动程
序共存，包括共享控制台系统驱动程序。
然而，模块化驱动不能接管现由另一个模块化的驱动程序掌控的控制台。 
（例外：调用do_take_over_console的驱动）将在收购成功，无论在何种类型
驱动程序占用的控制台）。他们只能接管系统驱动程序的控制台占用。
同样的道理，如果模块化驱动是控制台释放的，系统驱动程序也会接管。


Modular drivers, from the programmer's point of view, has 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 unbond


模块化驱动调用：


do_take_over_console() - 控制台层的驱动程序加载和绑定
give_up_console() - 当驱动完全无粘连时卸载程序


In newer kernels, the following are also available:


do_register_con_driver()
do_unregister_con_driver()


在较新的内核，也可用：


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


如果启用了sysfs，/sys/class/vtconsole中的内容可以受到检查。
而目前的控制台后端注册系统将被命名为vtcon<N>，其中<n>是从0到15的整数：


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


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


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


每个/sys/class/vtconsole下的目录内含三个文件：


     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:


1。绑定 - 这是一个读/写文件。它显示了状态的驱动程序，如果
        阅读，或行为来绑定或解除绑定的驱动程序的虚拟控制台
        当写入。可能的值有：


   0 - means the driver is not bound and if echo'ed, commands the driver
   to unbind
0 - 表示该驱动器未绑定，如果echo调用则驱动解除绑定


        1 - means the driver is bound and if echo'ed, commands the driver to
   bind
1 - 是指驱动程序绑定，如果echo调用则驱动绑定


        2 - name - read-only file. Shows the name of the driver in this format:
2 - 名称 - 只读文件。显示在此格式的驱动程序的名称：
 
cat /sys/class/vtconsole/vtcon0/name
(S) VGA+


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


   'VGA+' is the name of the driver

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


   '(S)'表示一个系统驱动, 能直接命令其绑定或松绑。


   'VGA+'是驱动的名称


cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device


   In this case, '(M)' stands for a (M)odular driver, one that can be
   directly commanded to bind or unbind.


cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device


   在这种情况下，'(M)'代表模块化驱动, 且能够直接绑定或松绑。

     3 - uevent - ignore this file
3 - UEVENT - 忽略这个文件


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.


解除绑定时，模块化驱动器上首先解除，那么系统
驱动程序接管由驱动空出的控制台。另一方面，绑定
将结合目前所占用的控制台驱动程序系统驱动程序。


NOTE1: Binding and unbinding must be selected in Kconfig. It's under:


Device Drivers -> Character devices -> Support for binding and unbinding
console drivers
注1：必须在Kconfig中选择绑定和解除绑定。


设备驱动程序 - >字符设备 - >支持绑定和解除绑定控制台驱动程序


NOTE2: If any of the virtual consoles are in KD_GRAPHICS mode, then binding or
unbinding will not succeed. An example of an application that sets the console
to KD_GRAPHICS is X.


注2：如果任何虚拟控制台的在KD_GRAPHICS模式下，那么绑定或解除绑定将不会成功。


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).


这个功能很有用吗？对于控制台驱动开发者来说是这是非常有用的。
解除绑定驱动程序的控制台层，可以卸载驱动程序进行更改，重新编译，
重新加载并重新绑定而不需要任何驱动程序重新启动内核。
对于普通用户可能想切换从framebuffer的控制台VGA控制台，反之亦然，
这个功能也使得这一切成为可能。 
（注：请读fbcon.txt文档/ FB下更多的细节）。


Notes for developers:
开发者注意事项：
=====================


do_take_over_console() is now broken up into:


     do_register_con_driver()
     do_bind_con_driver() - private function


give_up_console() is a wrapper to do_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.


do_take_over_console()被分成：


     do_register_con_driver()
     do_bind_con_driver() - private function


give_up_console()是do_unregister_con_driver()的包装，驱动程序必须
完全非绑定调用成功。 con_is_bound()将检查驱动程序是绑定与否。


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 do_register_con_driver()
   or do_take_over_console(). do_register_con_driver() will just add the driver to
   the console's internal list. It won't take over the
   console. do_take_over_console(), as it name implies, will also take over (or
   bind to) the console.


   1.所有驱动器，除了系统驱动程序，必须调用do_register_con_driver()
   或do_take_over_console()。 do_register_con_driver（）将驱动程序添加到
   控制台的内部列表。它不会接手控制台。
   而do_take_over_console()，就像它的名称所表明的，将接管（或绑定）控制台。
   
2. All resources allocated during con->con_init() must be released in
   con->con_deinit().
   
2. 所有用con->con_init() 申请的资源必须用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.
   
3. 所有用con->con_startup() 申请的资源必须在刚才绑定的驱动松绑时被释放。
   控制台层不会追加调用con->con_startup()，因此检查资源的释放的合法性全靠驱动。
   调用con_is_bound()在执行con->con_deinit()时将会有所帮助。如果调用返回false()，
   那么资源能被安全释放。这种平衡确保con->con_startup()申请资源时所有资源都可用。
   
4. Upon exit of the driver, ensure that the driver is totally unbound. If the
   condition is satisfied, then the driver must call do_unregister_con_driver()
   or give_up_console().


4. 在退出的驱动程序，确保驱动程序是完全非绑定的。如果
   条件满足时，则驱动程序必须调用do_unregister_con_driver()
   或give_up_console()。
   
5. do_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.
   
5. 当驱动不能回应控制台请求时do_unregister_con_driver()也能被调用。这种情况在
   帧缓冲控制台突然丢失驱动时会出现。
   
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@pol.net>