现在的位置: 首页 > 综合 > 正文

Documentation/console/console.txt

2013年12月13日 ⁄ 综合 ⁄ 共 7970字 ⁄ 字号 评论关闭
文章目录

Chinese translated version of Documentation/filesystems/ecryptfs.txt

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: 谢尚敬 <1479201451@qq.com>

---------------------------------------------------------------------

Documentation/console/console.txt的中文翻译

如果想评论或更新本文的内容,请直接联系原文档的维护者。如果你使用英文

交流有困难的话,也可以向中文版维护者求助。如果本翻译更新不及时或者翻

译存在问题,请联系中文版维护者。

中文版维护者: 谢尚敬 <1479201451@qq.com>

中文版翻译者: 谢尚敬 <1479201451@qq.com>

中文版校译者: 谢尚敬 <1479201451@qq.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

 

 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:

     如果sysfs被启用,那么将可以对/sys/class/vtconsole 的内容进行检查。这显示了,控制台的后台正在由被命名为 vtcon <n>(<n>为0 到 15的整数)的系统注册。因而

 

       ls /sys/class/vtconsole

        .  ..  vtcon0  vtcon1

 

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

     在 /sys/class/vtconsole 中,每个目录有 3 个文件:

 

     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. bind -这是一个读/写文件。它显示了,在写入时,驱动程序的行为是在读取、或绑定、或取消绑定到虚拟控制台中。可能的值包括:

 

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

     0-表示驱动程序不受约束,并且如果 echo'ed,就命令驱动程序解除绑定

 

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

     1-表示驱动程序被绑定,并且如果echo'ed,就命令驱动程序绑定

 

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

     2. name -为只读文件。在此格式中,显示驱动程序的名称:

 

        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

     (S) 代表 (S)系统驱动程序,即它不能被直接命令绑定或取消绑定

 

            'VGA+' is the name of the driver

 

          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.

在这种情况下,'(M)' 代表 (M) odular 驱动程序,一种可以直接命令绑定或取消绑定的程序。

 

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:

备注1:选择绑定和解除绑定必须在 kconfig 中进行选择。它是根据:

 

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

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

 

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 的模式下,那么绑定或取消绑定都将不会成功。其中一个例子就是,X是将控制台设置为 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).

这功能多有用?这对控制台驱动程序开发人员是很有用的。通过对控制台层驱动程序解除绑定,一名人员可以卸载并且更改、 重新编译、 重新加载以及重新绑定该驱动程序,而无需重新启动内核的驱动程序。对于可能经常想要从帧缓冲区控制台切换到 VGA 控制台(反之亦然)的用户,此功能让其成为可能。(注意注意注意:请阅读更多根据文档/fb fbcon.txt的详细信息,)。

 

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.

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.

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

 

   原文地址: http://lxr.linux.no/#linux+v3.11.6/Documentation/console/console.txt

抱歉!评论已关闭.