"무엇입니까 /dev/console
?" 에 대한 답변 이전의 대답 . 다른 두 질문에 대한 답을 알면 그 대답이 더 명확 할 것입니다.
Q1. "물리적 터미널 자체를 나타내는 장치 파일은 무엇입니까?"
그러한 장치 파일이 없습니다.
Q2. "무엇에 /dev/console
사용됩니까?"
Linux에서는 /dev/console
시작 및 종료 중에 메시지를 표시하는 데 사용됩니다. Stephen Kitt의 답변에서 지적했듯이 "단일 사용자 모드"에도 사용됩니다. 그것을 사용하는 것이 이치에 맞지 않습니다.
유닉스의 "좋은 옛날"은 /dev/console
전용 물리적 장치였습니다. 그러나 Linux에서는 그렇지 않습니다.
관련 증거
1. "실제 터미널 자체를 나타내는 장치 파일은 무엇입니까?"
이런 식으로 이해하려고 노력하겠습니다. /dev/tty{1..63}
그리고 /dev/pts/n
,하지와 관련된 프로세스 나 커널 장치 자체를 (가 에뮬레이션 있지만)를 나타내는 장치 파일입니다. /dev/tty0
에 하나 reprsents /dev/tty{1..63}
현재 뭔가에 의해 사용되는 (아마도 커널을또는 쉘 프로세스?). /dev/tty
프로세스 세션에서 현재 사용중인 제어 터미널을 나타냅니다. /dev/console
커널이 현재 사용하고있는 터미널을 나타냅니다.
커널이나 프로세스가 아닌 물리적 터미널 자체를 나타내는 장치 파일은 무엇입니까?
의 기본 장치 /dev/tty{1..63}
는 struct con_driver
입니다. 가능한 모든 드라이버를 보려면 https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console을 확인 하십시오.
이러한 기본 장치에 대한 장치 파일이 없습니다!
이를 관리하기위한 최소한의 사용자 공간 인터페이스 만 있습니다.
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
정말로 더 알고 싶다면 module 의 (M)
약자입니다 . 즉, 더미 콘솔 장치는로드 가능한 커널 모듈에 의해 제공되지 않습니다. 초기 커널 이미지 (일명 "내장")의 일부입니다.
두 번째로, bind
각 하위 디렉토리에 있는 파일 /sys/class/vtconsole
이 나타나서 어떤 vtconsole 장치가 활성화되어 있는지 알려줍니다. 0
활성 상태로 쓰면 더미로 전환되는 것으로 보입니다. (GUI VT는 영향을받지 않지만 텍스트 VT는 작동을 멈 춥니 다). 쓰기 1
더미 하나하면 활성화되지 않습니다. 두 방법 모두 실제 방법으로 다시 전환합니다. 코드를 올바르게 읽으면 트릭은 echo 1 > bind
모듈 (?!)로 빌드 된 콘솔 드라이버에서만 작동하는 것입니다.
들면 프레임 버퍼 구체적 콘솔, 다른 프레임 버퍼 장치 (결합에 대한 좀 더 많은 정보가 /dev/fb0
특정 가상 콘솔에 ...)를 https://kernel.org/doc/Documentation/fb/fbcon.txt이 . 여기에는 커널 옵션 fbcon:map=
또는이라는 명령 이 포함됩니다 con2fbmap
.
물론 세부 사항은 커널 버전, 아키텍처, 펌웨어, 장치, 드라이버 등에 따라 다를 수 있습니다. 실제로 위의 인터페이스를 사용하지 않아도됩니다. 커널은 수 i915
/ inteldrmfb
/ 당신이 그것을로드, 예를 들어 교체 할 때 인수 전화를 원하는대로 vgacon
.
내 EFI 시스템에없는 것 같습니다 vgacon
. 첫 번째로 더미 콘솔을 사용하고 두 번째로 1.2 초 후에는 fbcon
으로 실행됩니다 efifb
. 그러나 지금까지 나는 세부 사항이 무엇인지 신경 쓰지 않았습니다. 그냥 작동합니다.
$ dmesg | grep -C2 [Cc]onsole
[ 0.230822] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.233164] NR_IRQS: 65792, nr_irqs: 728, preallocated irqs: 16
[ 0.233346] Console: colour dummy device 80x25
[ 0.233571] console [tty0] enabled
[ 0.233585] ACPI: Core revision 20180810
[ 0.233838] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
--
[ 1.228393] efifb: scrolling: redraw
[ 1.228396] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 1.230393] Console: switching to colour frame buffer device 170x48
[ 1.232090] fb0: EFI VGA frame buffer device
[ 1.232110] intel_idle: MWAIT substates: 0x11142120
--
[ 3.595838] checking generic (e0000000 408000) vs hw (e0000000 10000000)
[ 3.595839] fb: switching to inteldrmfb from EFI VGA
[ 3.596577] Console: switching to colour dummy device 80x25
[ 3.596681] [drm] Replacing VGA console driver
[ 3.597159] [drm] ACPI BIOS requests an excessive sleep of 20000 ms, using 1500 ms instead
[ 3.599830] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
--
[ 3.657050] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[ 3.657869] e1000e 0000:00:19.0 eno1: renamed from eth0
[ 4.711453] Console: switching to colour frame buffer device 170x48
[ 4.734356] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 4.778813] Loading iSCSI transport class v2.0-870.
2. "무엇을 /dev/console
위해 사용됩니까?"
/ dev / console을 TTY 장치로 사용할 수 있습니다. 예를 들어 여기에 쓰면 특정 기본 장치에 쓰며 자체 장치 번호도 갖습니다.
종종 / dev / console은 / dev / tty0에 연결되어 있지만 때로는 다른 장치에 연결되어있을 수 있습니다.
따라서이 경우 / dev / console에 쓰면 / dev / tty0에 쓰게됩니다. 그리고 / dev / tty0에 쓰는 것은 현재 활성화 된 / dev / ttyN 장치에 쓰는 것과 같습니다.
그러나 이것은 흥미로운 질문을 제기합니다. 액세스 tty0
는 현재 활성 상태에 따라 다른 가상 콘솔에 액세스합니다. 사람들이 실제로 무엇을 위해 사용 tty0
하는 것과 비슷하게 console
Linux에서 사용되는 것은 무엇 입니까?
기술적으로 console
/ 에서 읽고 쓸 수 있습니다 ( tty0
예 : getty
로그인 허용) tty0
. 그러나 이것은 빠른 해킹으로 만 유용합니다. Linux의 여러 가상 콘솔을 활용할 수 없기 때문입니다.
systemd
sysfs
기본 TTY 장치를 감지하기 위해 / dev / console 장치와 관련된 속성을 찾습니다 . 이것은 사용자가로 부팅하여 커널 콘솔을 설정할 때 systemd
자동으로 a를 생성하고 getty
직렬 콘솔과 같은 로그인을 허용합니다 console=ttyS0
. 이것은 편리합니다. 이 콘솔을 서로 다른 두 곳에 구성 할 필요가 없습니다. 다시 참조하십시오 man systemd-getty-generator
. 그러나 systemd
실제로 /dev/console
이것을 열지는 않습니다 .
시스템 부트 스트랩 중에 sysfs가 아직 마운트되지 않았을 수도 있습니다. 그러나 가능한 빨리 오류 및 진행 메시지를 표시 할 수 있기를 원합니다! 그래서 우리는 1) 지점으로 돌고 있습니다. 커널은 stdin / stdout / stderr에 연결된 PID 1을 시작합니다 /dev/console
. 이 간단한 메커니즘을 처음부터 설정하는 것이 매우 좋습니다.
Linux 컨테이너 내에서 파일 /dev/console
은 문자 장치 번호가 아닌 다른 것으로 생성 될 수 있습니다 5:1
. 대신 PTS 장치 파일로 생성 될 수 있습니다. 그런 다음이 /dev/console
파일 을 통해 로그인하는 것이 좋습니다. systemd
컨테이너 내부에서는 그러한 장치에 로그인 할 수 있습니다. 참조하십시오 man systemd-getty-generator
.
이 메커니즘은 systemd-nspawn
명령 으로 컨테이너를 실행할 때 사용됩니다 . ( systemd-nspawn
Man 페이지를 검색하여 말할 수는 없지만 TTY 를 실행할 때만 생각 합니다).
systemd-nspawn
/dev/console
호스트에서 컨테이너를 PTS 장치의 바인드 마운트로 만듭니다 . 이는이 PTS 장치가 /dev/pts/
컨테이너 내부에서 보이지 않음을 의미합니다 .
PTS 장치는 특정 devpts
마운트에 로컬 입니다. PTS 장치는 장치 번호로 식별되는 일반적인 규칙의 예외입니다. PTS 장치는 장치 번호와 devpts
마운트 의 조합으로 식별됩니다 .
console
/에 긴급 메시지를 tty0
작성하여 사용자의 현재 가상 콘솔에 쓸 수 있습니다 . 이는 콘솔에 인쇄되는 긴급 커널 메시지와 유사한 긴급 사용자 공간 오류 메시지에 유용 할 수 있습니다 (참조 man dmesg
). 그러나 시스템 부팅이 완료된 후에는이 작업이 일반적이지 않습니다.
위해 rsyslog는이 이 페이지에 하나의 예 인쇄에 메시지를 커널, /dev/console
; 커널은 기본적으로 이미 그렇게하므로 Linux에서는 의미가 없습니다. 다시 찾을 수없는 한 예는 너무 많은 syslog 메시지가 있기 때문에 커널이 아닌 메시지에 이것을 사용하는 것이 좋지 않다는 것입니다.
systemd-journald도 마찬가지로 모든 로그를 콘솔에 전달하는 옵션이 있습니다. 원칙적으로 이는 가상 환경에서 디버깅하는 데 유용 할 수 있습니다. 그러나 디버깅을 위해 보통 /dev/kmsg
대신 진행합니다 . 커널 로그 버퍼에 저장하므로을 (를) 사용하여 읽을 수 있습니다 dmesg
. 커널 자체에서 생성 된 메시지와 마찬가지로 이러한 메시지는 현재 커널 구성에 따라 콘솔에 에코 될 수 있습니다.