현대 노트북의 절전 관리 역사부터 S0ix, 최대 절전 모드, 그리고 FreeBSD에서의 구현 현황까지 살펴봅니다.
현대의 노트북은 일종의 마법을 약속합니다. 덮개를 닫거나 절전 버튼을 누르고, 가방에 넣어 둔 뒤 몇 시간, 며칠, 혹은 몇 주가 지나도 배터리를 거의 또는 전혀 소모하지 않은 채 아무 일도 없었던 것처럼 깨어나야 합니다. 이것은 꽤 사소한 동작처럼 들립니다. 말하자면, 컴퓨터에게 정말로 아무것도 하지 말라고 하는 것이니까요. 하지만 팬 소리가 잦아들고, 화면이 어두워지며, 되비친 자신의 얼굴이 보이는 그 고요한 순간에도, 컴퓨터와 그 안의 작은 구성 요소들은 사실 잠자리에 들기 위한 루틴을 수행하느라 분주하게 움직이고 있습니다.
우리가 어디에서 출발했는지 더 잘 이해하기 위해, 컴퓨터 전원 관리의 역사를 한 번 천천히 살펴봅시다.
최초의 “모바일” 컴퓨터는 반쯤 휴대 가능한 기계에 더 가까웠고, 배터리가 있더라도 AC 전원에서 오래 떨어져 사용하도록 기대되지는 않았습니다. Osborne 1의 경우, 별매 배터리 확장 팩이 있기는 했지만, 실제로는 콘센트 사이를 옮겨 다니며 전원을 켰다 껐다 하며 쓰는 것이 전제였습니다.
오늘날 우리가 아는 의미의 최초의 진정한 모바일 컴퓨터는 아마 1983년에 출시된 Dulmont Magnum일 것입니다. 이 기기는 처음으로 “suspend-to-RAM” 기능을 도입했는데, 이 경우에는 메모리를 배터리 백업 CMOS RAM에 유지한 채 다른 구성 요소들의 전원을 끌 수 있다는 뜻이었습니다. 몇몇 다른 DOS 시스템들도 독자적인 절전 해법을 제공했지만, 대체로 꽤 임기응변적인 수준에 머물렀습니다.
1985년에 Intel은 i386 칩을 출시했고, 그중 SL 변형은 1990년에 출시되어 노트북과 같은 저전력 효율 기기를 겨냥했습니다. 이 칩은 SMM(System Management Mode)을 도입했는데, 이를 통해 CPU 실행을 운영체제에서 BIOS가 기록하고 잠가 둔 메모리 영역(SMBASE에서 시작하는 SMI 핸들러)으로 전환할 수 있었고, 그곳에서는 ring 0보다 더 높은 권한으로 전원 관리 코드를 실행할 수 있었습니다.
이 실행 전환은 SMI(System Management Interrupt)에 의해 시작되었으며, 이는 하드웨어(예: 전원 버튼 누름)에 의해 발생할 수도 있고, 운영체제가 특정 포트에 I/O 접근을 수행함으로써 발생시킬 수도 있었습니다. 이 전원 관리 방식에는 큰 결함이 있었는데, 그중에서도 가장 큰 문제는 이 구조에서 운영체제가 수동적인 존재였으며 펌웨어에 완전히 종속되어 있었다는 점입니다. 실제로 SMI가 하드웨어에 의해 발생하면 OS는 완전히 우회되었고, 실행은 사실상 그대로 얼어붙기 때문에, 절전 진입을 준비할 수 있는 능력이 전혀 없었습니다.
SMI 핸들러는 또한 익스플로잇의 매우 풍부한 원천이기도 했습니다. 특히 NSA의 악명 높은 ANT 카탈로그에 실린 많은 “implant”들이 대표적입니다. 이들은 원격으로 BIOS를 플래시하여 악성 페이로드가 SMBASE에 적재되도록 했고, 그 결과 해당 코드가 시스템 동작 중 주기적으로 실행될 수 있었습니다.
1992년에 도입된 APM(Advanced Power Management)은 마침내 x86 플랫폼을 위한 표준화된 전원 관리 인터페이스를 제공했습니다. 이전 같으면 SMI를 유발했을 사건이 발생했을 때, 이제 펌웨어는 단지 전원 관리 이벤트를 통해 OS에 이를 알리기만 합니다. 그러면 OS는 필요하다면 어떤 대응을 할지 스스로 결정하고, 실제로 펌웨어에 전원 상태 전환을 요청하기 전에 충분한 시간을 들여 준비할 수 있습니다. 이 요청은 APM 함수, 보통 BIOS 인터럽트 0x15를 통해 이루어졌습니다.
이것은 전원 관리 측면에서 SMM보다 엄청난 개선이었습니다. 다만 여전히 하나의 문제가 남아 있었습니다. APM은 BIOS 벤더가 버그투성이가 아닌 소프트웨어를 작성할 것이라고 가정했고, 이 APM 함수들은 BIOS에 상당히 많은 일을 요구하고 있었습니다.
결국 APM은 1996년에 ACPI(Advanced Configuration and Power Interface)로 대체되었습니다. ACPI는 하드웨어와 펌웨어가 운영체제와 통신하고 자신의 기능을 제공하기 위한 훨씬 더 포괄적인 표준이자 인터페이스였으며, 오늘날의 최신 시스템에서도 여전히 사용되고 있습니다.
ACPI는 전원 관리 책임을 펌웨어에서 OS 쪽으로 더 많이 옮기고자 했으며, 이를 “OSPM”(OS-directed Power Management)이라고 불렀습니다. ACPI는 시스템이 가질 수 있는 상위 수준의 전원 상태인 여러 “S” 상태를 정의합니다.
가장 눈에 띄는 것은 S0(컴퓨터가 완전히 깨어 실행 중인 상태), S3(컴퓨터가 suspend-to-RAM 상태인 경우), S4(컴퓨터가 suspend-to-disk, 즉 최대 절전 상태인 경우), 그리고 S5(컴퓨터가 종료된 상태)입니다. 하지만 본질적으로 S3를 통한 절전은 APM과 비슷한 접근을 따릅니다. 즉, “OS가 전원 이벤트를 전달받고, 절전 여부를 결정하고 준비한 뒤, 마지막으로 펌웨어에 실제 절전을 요청한다”는 흐름이 유지되기 때문입니다.
그러나 하드웨어가 발전하고, 버릇없는 소비자인 우리가 그 하드웨어에서 더 많은 것을 기대하게 되면서, 이 흐름, 그리고 사실상 “시스템은 완전히 켜져 있거나 완전히 절전 상태이거나 둘 중 하나”라는 전체 패러다임은 한계를 드러내기 시작했습니다.
스마트폰과 유사한 장치가 등장하면서, 이제 우리는 덮개가 닫혀 있어도 기기가 항상 연결된 상태이기를 기대하게 되었습니다. 좋아하는 AI 슬롭 콘텐츠 제작자의 새 업로드 알림도 받고 싶고, 구독 중인 500번째 뉴스레터 이메일도 받고 싶고, 일정 이벤트를 알려 주기 위해 시스템이 깨어나길 원합니다.
이를 위해서는 때때로, 혹은 wake-on-LAN 패킷을 받았을 때 시스템을 깨워서, 예를 들어 패킷을 조금 더 자세히 살펴보고 정말로 시스템을 완전히 깨울지 아니면 즉시 다시 잠들게 할지를 결정해야 합니다. 그런데 이런 사용 사례는 S3로는 제대로 수용하기에 너무 경직되어 있습니다. S3는 펌웨어가 모든 것을 다시 시작하는 데 드는 에너지와 시간이 너무 많이 듭니다.
S3는 전부 아니면 전무입니다. 거기서 깨어나려면, 사실상 매번 완전히 복귀하는 것처럼 동작해야 합니다.
해결책이 있다면 얼마나 좋을까요…
2018년 무렵 어딘가에서, 컴퓨터가 가능한 한 효율적으로 절대 아무 일도 하지 않게 만들려는 끝없는 탐구 속에서, Intel은 S0ix를 도입했습니다. S0ix는 실제로는 여러 상태(S0i1, S0i2, S0i3, 경우에 따라 그 이상)의 집합입니다. 하지만 중요한 점은 이 상태들이 모두 시스템을 ACPI의 S0, 즉 깨어 있는 상태에 그대로 둔다는 것입니다. 일반적으로 “x”가 클수록 더 깊은 수면 상태이며 더 많은 전력 절감이 이루어지고, 목표는 대개 S0i3입니다. S0i0를 S0와 동등한 것으로 부르기도 하지만, 저는 그것이 다소 혼란스럽다고 생각하므로 그 용어는 사용하지 않겠습니다.
과거의 S3나 APM과 달리, OS는 실제로 펌웨어에 S0ix 진입을 명시적으로 요청하지 않습니다. 아니, 실은 실제 구현에서는 어느 정도 그렇게 하긴 하지만, 그건 뒤에서 다시 이야기하겠습니다. 대신 OS는 S0ix 상태로 진입하는 데 필요한 조건을 만들어 두고, CPU를 언제 어떤 S0ix 상태로 전환할지는 펌웨어가 스스로 결정하게 둡니다.
그 필요한 조건은 다음과 같습니다.
장치 전원을 어떻게 내리는지 살펴봅시다.
S0ix를 지원하는 시스템은 SPMC(System Power Management Controller, 때로는 PEP라고도 함)라는 ACPI 장치를 노출합니다. ACPI 세계에서 DSM(Device-Specific Method)이라 불리는 함수들을 이 SPMC 장치에 대해 호출하여, OS가 절전에 들어갈 의도가 있음을 플랫폼에 힌트로 제공할 수 있습니다. 또한 펌웨어가 S0ix 상태에 진입하기 위해 특정 장치가 최소한 어느 전원 상태에 있어야 하는지도 이 방법으로 제약 조건을 가져올 수 있습니다.
장치 전원 상태는 “D-state”라고 하며, D0(완전히 켜짐)에서 D3hot(꺼졌지만 전원은 공급됨), D3cold(꺼졌고 전원도 공급되지 않음)까지 존재합니다. 전체 절전을 수행하는 경우라면 D-state 제약이 꼭 요구하지 않더라도 장치를 D3cold로 전환하고 싶을 때가 많습니다. 하지만 장치를 깨우기 장치로 사용하려면 더 깨어 있는 D-state에 유지하고 싶을 수도 있습니다. 당연히 시스템을 깨우라는 신호를 보내야 하는 장치의 전원을 꺼 버리면, 우리는 결코 시스템을 깨울 수 없게 됩니다.
그래서 단순하게 말하면, SPMC가 제공하는 이 제약들은 절전 중에 장치를 켜 둔 것이 S0ix 진입을 방해하는지만 알려 줍니다. CPU를 유휴 상태로 만드는 방법으로는 suspend-to-idle, 즉 s2idle이라는 특별한 소프트웨어 상태에 진입합니다. 이것은 사실상 예전의 S3를 대체합니다. 본질적으로는 스케줄러 클록을 멈추고, OS가 실행하던 것을 일시 중단하여 시스템의 모든 CPU를 저전력 유휴 상태로 넣는 방식입니다. 이러한 저전력 유휴 상태를 C-state라고 하며, 그 진입 방법과 기타 정보는 더 오래된 _CST ACPI 객체나, 그보다 현대적인 대체물인 _LPI 객체를 통해 얻습니다.
유휴 상태에서 빠져나오는 것은 CPU에 인터럽트를 걸어 이루어집니다. 따라서 유휴 상태에 들어가기 전에, 실제로 CPU를 깨우는 데 사용하고자 하는 인터럽트만 남기고 모든 CPU 인터럽트를 비활성화합니다. 이러한 깨우기 인터럽트는 보통 SCI(ACPI System Control Interrupt)인데, 이를 통해 GPE(General Purpose Event)가 발생했음을 알 수 있습니다. GPE는 예를 들어 전원 버튼을 누르거나 덮개를 여는 것일 수 있으며, 대략적으로는 “GPE 번호”로 구분됩니다.
SCI는 깨어나기와 무관한 여러 이유로도 발생할 수 있으므로, 실제 깨어나기 GPE에서만 SCI가 발생하도록 ACPI를 최대한 잘 구성합니다. 하지만 이것은 말처럼 쉽지 않은 경우가 많습니다. 이것도 뒤에서 다시 이야기하겠습니다.
이론적으로는 두 조건이 모두 충족되면, 펌웨어가 CPU 패키지 전원을 끊고 S0ix 상태에 진입할 수 있습니다. 하지만 실제로는 상황이 좀 더 복잡하고 하드웨어별 차이도 큽니다.
예를 들어 AMD 시스템에서는 전원 관리 펌웨어가 SMU(System Management Unit)라는 이름의 작은 온다이 LatticeMico32 코어에서 실행되며, 최근에는 이것을 “MP1” 칩이라고 부르는 경우도 볼 수 있습니다. 이것이 궁극적으로 CPU 패키지의 클록 게이팅과 전원 게이팅을 담당하며, 따라서 패키지를 S0ix 상태 안팎으로 전환하는 역할을 맡습니다.
OS가 실제로 절전에 들어가고자 할 때는, PMFW에 S0i3에 진입하라는 작은 명령을 보내 힌트를 주어야 합니다. SMU에는 일반적인 S0ix 요구 조건 외에도 별도의 요구 사항이 있습니다. 그중 가장 눈에 띄는 것은 GPU와 USB4 컨트롤러 관련 요구 사항입니다. 최근 버전의 amdgpu 드라이버는 S3 또는 S0ix에 진입할 때 서로 다른 경로를 사용하며, USB4 컨트롤러는 NHI 드라이버에 의해 명시적으로 전원이 꺼져야 합니다. 이것은 운영체제가 USB4를 지원하지 않더라도 필요합니다. 왜냐하면 이 컨트롤러들은 pre-OS connection manager에 의해 활성화되며, 이 관리자는 OS가 부팅되기 전에 USB4가 동작하려면 필요하고, OS가 부팅할 시점에도 컨트롤러는 여전히 활성 상태로 남아 있기 때문입니다.
SMU는 또한 디버깅 정보도 전달하여, 시스템이 S0i3에 성공적으로 진입했는지, 그렇지 않았다면 무엇이 이를 막았는지를 사용자에게 알려 줍니다. 이 정보는 FreeBSD에서 dev.amdsmu.0.ip_blocks 및 dev.amdsmu.0.metrics sysctl 트리를 통해 노출됩니다.
PMFW는 순전히 온다이에서 실행되므로, 플랫폼 전체에 우리가 S0ix에 들어가려는 의사를 알리기 위해서는 앞서 언급한 “display off”와 “entry” 알림 DSM을 통해 SPMC에 절전 진입 의사를 알려야 합니다. 그러면 보통 플랫폼은 시스템이 절전 상태임을 사용자에게 시각적으로 보여 줍니다. 예를 들어 Framework 노트북에서는 전원 버튼 LED가 천천히 밝아졌다 어두워지는 식입니다. 또한 더 미묘한 일도 할 수 있는데, 예를 들면 그렇지 않으면 CPU를 유휴 상태, 따라서 S0i3 상태에서 계속 깨워 버릴 일부 GPE의 발생 빈도를 줄이는 것입니다.
실제로 Framework 노트북에서는 EC(Embedded Controller)가 정상 동작 중 배터리 장치에 대해 약 1초에 한 번꼴로 GPE를 보냅니다. 그런데 절전에 들어가기 전에 이것을 억제할 수는 없습니다. 배터리 GPE와 덮개 GPE가 같은 번호를 공유하기 때문입니다. 그래서 시끄러운 배터리 GPE를 끄고 싶다면, 대신 덮개로 시스템을 깨우는 기능을 포기해야 하는데, 그건 곤란합니다.
SPMC에 절전 진입을 알리면, EC는 배터리 GPE를 약 1분에 한 번 정도만 보내게 됩니다. S0i3에서 얼마나 빠르게 빠져나왔다가 다시 들어갈 수 있는지를 생각하면, 이것은 완전히 괜찮습니다. 그리고 시스템이 가끔 깨어나는 것은 suspend-to-idle 상태에서 시간에 따라 전력 소모와 배터리 상태가 어떻게 변하는지 추적하는 데 오히려 꽤 편리할 수 있습니다. 물론 RTC 알람으로도 아마 비슷한 일을 할 수 있겠지만, 이야기가 옆길로 새니 여기서는 넘어가겠습니다.
CPU가 유휴 상태에서 깨어나는 이유는 아주 다양하고, 그 모든 경우가 시스템 전체를 깨우고 싶다는 뜻은 아닐 수 있으므로, CPU를 유휴 상태로 둘 때 “s2idle loop” 안에 넣습니다. 이렇게 하면 시스템에서 받은 GPE를 실제로 살펴보고 그것이 깰 가치가 있는지 결정할 수 있습니다. 이 GPE는 단순히 시끄러운 배터리 이벤트일 수도 있고, NIC에서 오는 wake-on-LAN 이벤트처럼 더 복잡한 것일 수도 있습니다. 앞서 언급했듯이, 그런 경우에는 시스템을 깨울지 결정하기 전에 패킷을 좀 더 자세히 살펴보고 싶을 수 있습니다.
종합하면, S0ix를 지원하는 시스템에서 절전에 들어가는 전체 흐름은 다음과 같습니다.
복귀는 사실상 처음 세 단계를 반대로 수행하는 것과 거의 같습니다.
자, 독자 여러분, 이쯤에서 “좋긴 한데, 내 노트북이 자는 동안 알림에 반응할 필요는 없어. 굳이 이 최신식 S0ix를 신경 써야 하나? 그냥 S3를 쓰면 되잖아?”라고 생각할지도 모르겠습니다. 그런데 안타깝게도 대답은, 오늘날 대부분의 최신 시스템은 더 이상 S3 지원 자체를 제공하지 않고, 그것을 완전히 S0ix로 대체했다는 것입니다.
둘 다 지원하는 것은 벤더에게 매우 복잡한 일이라서, 이제는 대부분 그렇게 하지 않습니다. 특히 주요 운영체제들은 대부분 S0ix를 이미 잘 지원하기 때문입니다. 다행히도 FreeBSD도 suspend-to-idle과 S0ix 지원을 추가하는 길을 착실히 가고 있습니다.
시스템이 suspend-to-idle을 지원하는지는 kern.power.supported_stype sysctl을 확인해 볼 수 있고, 특정 이벤트에서 ACPI가 suspend-to-idle에 들어가도록 hw.acpi sysctl 트리를 통해 설정할 수 있습니다. 그리고 시스템이 이를 지원하고 FreeBSD도 지원한다면, S0ix 상태는 자동으로 진입되어야 합니다.
현재로서는 이를 확인하는 통합된 방법은 없지만, SMU 칩이 있는 AMD 시스템이라면 앞서 언급한 SMU sysctl들을 사용할 수 있습니다.
S0i3를 동작시키기 위해 이 모든 노력을 기울이고 나면, S0i3에서조차 전력 절감 효과가 그리 뛰어나지 않다는 사실을 알고 조금 실망할 수도 있습니다. 사실 S3도 마찬가지입니다. 이 부분은 시스템마다 차이가 크지만, S0i3 상태에서 며칠 정도밖에 버티지 못하는 시스템도 전혀 드문 일이 아닙니다. 그래서 hibernate, 즉 suspend-to-disk가 등장합니다.
S3나 S0i3처럼 메모리로 절전할 때는, 시스템이 계속해서 DRAM을 리프레시해야 하는데, 이것은 결코 무시할 수 있는 전력 소모원이 아닙니다. 게다가 시스템 메모리가 많아질수록 이 소모는 더 커집니다. 반면 suspend-to-disk에서는 메모리 내용을 하드 드라이브에 복사하고, 사실상 컴퓨터를 완전히 끄게 됩니다. DRAM도 포함해서 말입니다. 마치 시스템을 종료하는 것과 같습니다. 사실상 모든 실용적인 의미에서 정말 종료하는 것이니까요. 이 말은 시스템이 거의 전력을 소비하지 않는다는 뜻입니다. 적극적으로 전력을 소비하는 구성 요소는 EC가 있는 시스템이라면 그런 것 정도인데, 그것조차 어차피 시스템 전원이 꺼져 있을 때와 다르지 않습니다.
ACPI의 S-state 용어로 말하면, hibernate는 S4입니다.
아주 초창기, 아직 공룡이 지구를 돌아다니던 시절에는, BIOS 벤더들이 도입을 쉽게 하기 위해 S4BIOS라는 것을 펌웨어에 구현했습니다. 이 구조에서는 suspend-to-RAM이 APM 이전에 그랬던 것처럼, BIOS가 OS 메모리를 디스크에 복사하는 일을 전적으로 담당했습니다.
FreeBSD는 S4BIOS를 지원하지만, 오늘날 대부분의 운영체제는 일반적인 S4 hibernate만 지원하므로 오래전부터 실질적인 중요성은 사라졌습니다. S4에서는 운영체제가 자신의 메모리를 디스크에 복사하는 대부분의 작업을 담당하고, 펌웨어는 본질적으로 시스템 전원을 끄기만 합니다. 사실 플랫폼에 펌웨어 차원의 S4 지원이 전혀 없어도 hibernate를 완전히 구현할 수 있습니다. 그저 플랫폼의 전원 끄기 기능을 사용하면 되기 때문입니다. ACPI 플랫폼에서는 그것이 S5이고, 비ACPI 플랫폼에서는 그에 해당하는 다른 기능이 됩니다.
hibernate의 가장 큰 단점은 진입과 복귀 시 지연 시간입니다. 운영체제가 모든 페이지를 디스크에 복사할 때까지 기다려야 하고, 복귀 시에는 부팅 과정의 상당 부분을 다시 거친 뒤 마지막에 그 페이지들을 디스크에서 메모리로 복원해야 합니다. 하지만 실제로는 S0ix와 hibernate의 장점을 결합한 하이브리드 접근도 가능합니다.
RTC 알람을 설정하면, 시스템을 예를 들어 한 시간 동안 S0i3에 머물게 한 뒤, 그 사이에 사용자가 시스템을 깨우지 않았다면 다시 깨어나 hibernate로 진입하게 할 수 있습니다. 이렇게 하면 절전 후 한 시간 이내에 시스템을 깨우는 경우에는 S0ix의 매우 빠른 복귀 시간을 누릴 수 있고, 반대로 하룻밤 이상 혹은 며칠 동안 시스템을 절전 상태로 두는 경우에는 hibernate의 훨씬 더 나은 배터리 수명을 얻을 수 있습니다. 물론 한 시간 내에 깨우지 않았다면 다음에 시스템을 깨울 때 복귀 시간이 상당히 더 길어지겠지만, 전반적으로 보면 꽤 괜찮은 절충안입니다.
이 하이브리드 접근으로는 다른 멋진 일도 할 수 있습니다. 예를 들어 ACPI
_BLT (Battery Level Threshold) 제어 메서드를 구성하여 배터리가 특정 임계값, 예를 들어 5%에 도달하면 시스템을 깨우도록 만들 수 있습니다. 그러면 S0ix 상태에서 배터리가 완전히 소진되어 강제 전원 종료가 일어나기 전에 hibernate로 진입할 수 있습니다.
FreeBSD Foundation은 “Laptop Support and Usability Project”의 일환으로 S0ix와 hibernate에 대한 후원 개발 작업을 주도해 왔습니다. suspend-to-idle과 S0ix 관련 코드의 상당 부분은 이미 반영되었고, hibernate 작업도 최근 시작되었지만, S0i3 진입과 특히 그로부터의 복귀는 아직 완전히 신뢰할 수 있는 수준은 아니며, SMU를 만족시키기 위해 필요한 USB4 드라이버의 구성 요소들도 아직 반영되지 않았습니다.
게다가 현재까지의 많은 초점은 Intel보다는 AMD 시스템에 맞추어져 있었습니다. 다만 Intel의 경우에도 그들의 SMU에 해당하는 PMC 드라이버의 초기 작업이 최근 시작되기는 했습니다. AMD 플랫폼 안에서도 지금까지의 테스트는 Phoenix에서만 이루어졌고, amdsmu 드라이버는 이론적으로 Cezanne, Rembrandt, Phoenix 칩만 지원합니다.
진행 중인 USB4 드라이버(thunderbolt)로 테스트된 유일한 USB4 컨트롤러는 Pink Sardine(Phoenix 시스템에서 발견됨)이지만, 일반적인 별도 특이점 없는 USB4 컨트롤러들도 지원되어야 합니다.
이 글을 쓰는 시점에서 남아 있는 작업의 많은 부분은 가장 깊은 C-state(Phoenix 시스템에서는 C3)에 안정적으로 진입하는 데 집중되어 있습니다. CPU가 종종 예기치 않게 깨어나고, 그 결과 시스템이 S0i3를 벗어나기 때문입니다. 하지만 잘되기를 바라 봅시다. FreeBSD도 곧 modern standby와 hibernate를 지원하게 되어 Linux와 Windows에 완전히 뒤처지지 않게 되기를요!
S0ix와 FreeBSD에서의 구현을 좀 더 기술적이고 집중적으로 살펴보고 싶고, 추가 참고 자료도 보고 싶다면, 제 블로그를 참고하실 수 있습니다: https://obiw.ac/s0ix
Aymeric Wibo는 벨기에 출신의 소프트웨어 프리랜서로, 커널 개발과 그래픽스 프로그래밍을 전문으로 합니다. 그는 고등학교 시절부터 FreeBSD에 참여해 왔으며, 현재는 FreeBSD Foundation에서 노트북 전원 관리 작업을, 그리고 Klara Inc.에서 업무를 하고 있습니다.
