“무엇입니까 /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하는 것과 비슷하게 consoleLinux에서 사용되는 것은 무엇 입니까?

1. 기술적으로 console/ 에서 읽고 쓸 수 있습니다 ( tty0예 : getty로그인 허용) tty0. 그러나 이것은 빠른 해킹으로 만 유용합니다. Linux의 여러 가상 콘솔을 활용할 수 없기 때문입니다.

2. systemdsysfs기본 TTY 장치를 감지하기 위해 / dev / console 장치와 관련된 속성을 찾습니다 . 이것은 사용자가로 부팅하여 커널 콘솔을 설정할 때 systemd자동으로 a를 생성하고 getty직렬 콘솔과 같은 로그인을 허용합니다 console=ttyS0. 이것은 편리합니다. 이 콘솔을 서로 다른 두 곳에 구성 할 필요가 없습니다. 다시 참조하십시오 man systemd-getty-generator. 그러나 systemd실제로 /dev/console이것을 열지는 않습니다 .

3. 시스템 부트 스트랩 중에 sysfs가 아직 마운트되지 않았을 수도 있습니다. 그러나 가능한 빨리 오류 및 진행 메시지를 표시 할 수 있기를 원합니다! 그래서 우리는 1) 지점으로 돌고 있습니다. 커널은 stdin / stdout / stderr에 연결된 PID 1을 시작합니다 /dev/console. 이 간단한 메커니즘을 처음부터 설정하는 것이 매우 좋습니다.

4. Linux 컨테이너 내에서 파일 /dev/console은 문자 장치 번호가 아닌 다른 것으로 생성 될 수 있습니다 5:1. 대신 PTS 장치 파일로 생성 될 수 있습니다. 그런 다음이 /dev/console파일 을 통해 로그인하는 것이 좋습니다. systemd컨테이너 내부에서는 그러한 장치에 로그인 할 수 있습니다. 참조하십시오 man systemd-getty-generator.

   이 메커니즘은 systemd-nspawn명령 으로 컨테이너를 실행할 때 사용됩니다 . ( systemd-nspawnMan 페이지를 검색하여 말할 수는 없지만 TTY 를 실행할 때만 생각 합니다).

   systemd-nspawn/dev/console호스트에서 컨테이너를 PTS 장치의 바인드 마운트로 만듭니다 . 이는이 PTS 장치가 /dev/pts/컨테이너 내부에서 보이지 않음을 의미합니다 .

   PTS 장치는 특정 devpts마운트에 로컬 입니다. PTS 장치는 장치 번호로 식별되는 일반적인 규칙의 예외입니다. PTS 장치는 장치 번호와 devpts마운트 의 조합으로 식별됩니다 .

5. console/에 긴급 메시지를 tty0작성하여 사용자의 현재 가상 콘솔에 쓸 수 있습니다 . 이는 콘솔에 인쇄되는 긴급 커널 메시지와 유사한 긴급 사용자 공간 오류 메시지에 유용 할 수 있습니다 (참조 man dmesg). 그러나 시스템 부팅이 완료된 후에는이 작업이 일반적이지 않습니다.

   위해 rsyslog는이 이 페이지에 하나의 예 인쇄에 메시지를 커널, /dev/console; 커널은 기본적으로 이미 그렇게하므로 Linux에서는 의미가 없습니다. 다시 찾을 수없는 한 예는 너무 많은 syslog 메시지가 있기 때문에 커널이 아닌 메시지에 이것을 사용하는 것이 좋지 않다는 것입니다.

   systemd-journald도 마찬가지로 모든 로그를 콘솔에 전달하는 옵션이 있습니다. 원칙적으로 이는 가상 환경에서 디버깅하는 데 유용 할 수 있습니다. 그러나 디버깅을 위해 보통 /dev/kmsg대신 진행합니다 . 커널 로그 버퍼에 저장하므로을 (를) 사용하여 읽을 수 있습니다 dmesg. 커널 자체에서 생성 된 메시지와 마찬가지로 이러한 메시지는 현재 커널 구성에 따라 콘솔에 에코 될 수 있습니다.

답변