요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
===============
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 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.
Modular drivers, from the programmer's point of view, have 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 unbound
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::
ls /sys/class/vtconsole
. .. vtcon0 vtcon1
Each directory in /sys/class/vtconsole has 3 files::
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:
0
- means the driver is not bound and if echo'ed, commands the driver
to unbind
1
- means the driver is bound and if echo'ed, commands the driver to
bind
2. name - read-only file. Shows the name of the driver in this format::
cat /sys/class/vtconsole/vtcon0/name
(S) VGA+
'(S)' stands for a (S)ystem driver, i.e., it cannot be directly
commanded to bind or unbind
'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.
3. uevent - ignore this file
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
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.
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
====================
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.
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.
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 do_unregister_con_driver()
or 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.
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>
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
콘솔 드라이버의 두 유형
1-21.. SPDX-License-Identifier: GPL-2.0
Linux 커널에는 일반적으로 두 종류의 콘솔 드라이버가 있습니다. 첫 번째 유형은 부팅 과정에서 커널이 모든 가상 콘솔에 할당합니다. 이 문서에서는 이를 '시스템 드라이버'라고 부릅니다. 시스템 드라이버는 하나만 존재할 수 있고 영속적이어서 언로드할 수 없지만, 비활성 상태가 될 수는 있습니다.
두 번째 유형은 명시적으로 로드하고 언로드해야 하며, 이 문서에서는 '모듈식 드라이버'라고 부릅니다. 여러 모듈식 드라이버가 동시에 존재하면서 시스템 드라이버를 포함한 다른 드라이버와 콘솔을 나눠 사용할 수 있습니다.
다만 모듈식 드라이버는 다른 모듈식 드라이버가 현재 점유한 콘솔을 넘겨받을 수 없고, 시스템 드라이버가 점유한 콘솔만 넘겨받을 수 있습니다. 예외적으로 `do_take_over_console()`을 호출하는 드라이버는 점유 중인 드라이버 유형과 관계없이 인계에 성공합니다. 모듈식 드라이버가 콘솔에서 해제되면 시스템 드라이버가 다시 콘솔을 넘겨받습니다.
등록, 인계와 해제 API
22-33프로그래머 관점에서 모듈식 드라이버는 다음 함수를 호출해야 합니다. `do_take_over_console()`은 드라이버를 로드해 콘솔 계층에 바인딩하고, `give_up_console()`은 드라이버를 언로드합니다. 후자는 드라이버가 완전히 언바인드된 경우에만 동작합니다.
do_take_over_console() - load and bind driver to console layer
give_up_console() - unload driver; it will only work if driver
is fully unbound
더 새로운 커널에서는 콘솔 드라이버를 등록하거나 등록 해제하는 다음 함수도 사용할 수 있습니다.
do_register_con_driver()
do_unregister_con_driver()
vtconsole sysfs 인터페이스
34-82sysfs가 활성화돼 있으면 `/sys/class/vtconsole`의 내용을 살펴볼 수 있습니다. 이 디렉터리는 현재 시스템에 등록된 콘솔 백엔드를 보여 줍니다. 백엔드 이름은 `vtcon<n>` 형식이며, `<n>`은 0부터 15까지의 정수입니다.
ls /sys/class/vtconsole
. .. vtcon0 vtcon1
`/sys/class/vtconsole`의 각 디렉터리에는 `bind`, `name`, `uevent` 세 파일이 있습니다.
ls /sys/class/vtconsole/vtcon0
. .. bind name uevent
`bind`는 읽기와 쓰기가 가능한 파일입니다. 읽으면 드라이버의 바인딩 상태를 표시하고, 값을 쓰면 드라이버를 가상 콘솔에 바인딩하거나 가상 콘솔에서 언바인드합니다.
0
- means the driver is not bound and if echo'ed, commands the driver
to unbind
1
- means the driver is bound and if echo'ed, commands the driver to
bind
`0`은 드라이버가 바인딩되지 않았음을 뜻하며, 이 값을 쓰면 드라이버를 언바인드하라는 명령이 됩니다. `1`은 드라이버가 바인딩됐음을 뜻하며, 이 값을 쓰면 드라이버를 바인딩하라는 명령이 됩니다.
`name`은 읽기 전용 파일이며 정해진 형식으로 드라이버 이름을 보여 줍니다.
cat /sys/class/vtconsole/vtcon0/name
(S) VGA+
`(S)`는 직접 바인딩 또는 언바인딩을 명령할 수 없는 시스템 드라이버를 뜻하고, `VGA+`는 드라이버 이름입니다.
cat /sys/class/vtconsole/vtcon1/name
(M) frame buffer device
이 예에서 `(M)`은 직접 바인딩 또는 언바인딩을 명령할 수 있는 모듈식 드라이버를 뜻합니다. `uevent` 파일은 이 문서에서는 무시합니다.
언바인딩할 때는 먼저 모듈식 드라이버를 분리한 다음, 시스템 드라이버가 비워진 콘솔을 넘겨받습니다. 반대로 바인딩하면 현재 시스템 드라이버가 점유한 콘솔에 해당 드라이버가 연결됩니다.
바인딩 조건과 활용
83-102참고 1: 콘솔 드라이버 바인딩과 언바인딩 기능은 Kconfig에서 선택해야 합니다. 설정 경로는 다음과 같습니다.
Device Drivers ->
Character devices ->
Support for binding and unbinding console drivers
참고 2: 가상 콘솔 중 하나라도 `KD_GRAPHICS` 모드에 있으면 바인딩이나 언바인딩이 성공하지 않습니다. 콘솔을 `KD_GRAPHICS`로 설정하는 응용 프로그램의 예로 X가 있습니다.
이 기능은 콘솔 드라이버 개발자에게 특히 유용합니다. 드라이버를 콘솔 계층에서 언바인드하면 커널을 재부팅하지 않고도 드라이버를 언로드하고, 수정하고, 다시 컴파일하고, 재로드한 뒤 재바인딩할 수 있습니다.
일반 사용자도 이 기능으로 framebuffer 콘솔과 VGA 콘솔 사이를 전환할 수 있습니다. 자세한 내용은 `Documentation/fb` 아래의 `fbcon.txt`를 참고하십시오.
개발자 참고 사항
103-114`do_take_over_console()`의 기능은 이제 다음 두 함수로 나뉘었습니다.
do_register_con_driver()
do_bind_con_driver() - private function
`do_bind_con_driver()`는 비공개 함수입니다. `give_up_console()`은 `do_unregister_con_driver()`를 감싸는 래퍼이며, 이 호출이 성공하려면 드라이버가 완전히 언바인드돼 있어야 합니다. `con_is_bound()`로 드라이버의 바인딩 여부를 확인할 수 있습니다.
콘솔 드라이버 작성 지침
115-152콘솔과의 바인딩 및 언바인딩이 올바르게 동작하려면 콘솔 드라이버는 다음 지침을 따라야 합니다.
1. 시스템 드라이버를 제외한 모든 드라이버는 `do_register_con_driver()` 또는 `do_take_over_console()`을 호출해야 합니다. `do_register_con_driver()`는 드라이버를 콘솔의 내부 목록에 추가할 뿐 콘솔을 넘겨받지는 않습니다. 이름이 뜻하듯 `do_take_over_console()`은 등록과 함께 콘솔을 넘겨받거나 콘솔에 바인딩합니다.
2. `con->con_init()`에서 할당한 모든 자원은 `con->con_deinit()`에서 해제해야 합니다.
3. `con->con_startup()`에서 할당한 모든 자원은 이전에 바인딩됐던 드라이버가 언바인드될 때 해제해야 합니다. 콘솔 계층에는 `con->con_startup()`에 대응하는 호출이 없으므로, 자원을 해제해도 되는 시점을 드라이버가 직접 확인해야 합니다.
`con->con_deinit()`에서 `con_is_bound()`를 호출하면 이 판단에 도움이 됩니다. 호출 결과가 `false()`이면 자원을 해제해도 안전합니다. 드라이버 재바인딩 요청이 오면 `con->con_startup()`이 다시 호출될 수 있으므로 이 할당과 해제의 균형을 반드시 보장해야 합니다.
4. 드라이버가 종료될 때 완전히 언바인드됐는지 확인해야 합니다. 조건을 만족하면 드라이버는 `do_unregister_con_driver()` 또는 `give_up_console()`을 호출해야 합니다.
5. 드라이버가 콘솔 요청을 처리할 수 없게 된 경우에도 `do_unregister_con_driver()`를 호출할 수 있습니다. 예를 들어 framebuffer 콘솔이 갑자기 자신의 드라이버를 모두 잃은 경우가 이에 해당합니다.
현재의 콘솔 드라이버들은 계속 올바르게 동작해야 하지만 바인딩하거나 언바인딩할 때 문제가 생길 수 있습니다. 최소한의 수정으로 이 드라이버들이 올바르게 동작하도록 만들 수 있습니다. 원문 작성자는 Antonino Daplas `<adaplas@pol.net>`입니다.
요약과 해설
console.rst:1-152이 문서는 콘솔 소유권이 시스템 드라이버와 모듈식 드라이버 사이에서 이동하는 규칙을 설명하고, `/sys/class/vtconsole`을 통한 바인딩 제어와 개발자가 지켜야 할 자원 해제 규약을 정리합니다. 영어 원문 전체와 한국어 전문 번역을 함께 제공하며 함수명, sysfs 경로, 설정 경로와 원문 줄 좌표를 보존합니다.