Asahi Linux, Linux 7.0 에 대한 진행보고서가 올라 왔습니다.

 

 

어느덧 2026년도 1/3 이 지나고 있는데요,
20206년 4월 26일. Asahi Linux Kernel 7.0에 대한 진행보고서가 공식 블로그에 등록되었습니다.  진행보고서는 현재 릴리즈된 kernel 에 대한 것이 아니며, kernel 7.0 에 어떠한 것들이 추가되거나 검토되고 있는지에 대한 보고서 입니다. 따라서 보고서에서 논의되는 내용들은 진행과정에서 실제 적용이 더 늦쳐 질 수도 있다는 점을 고려해야 합니다.   

Asahi Linux는 Fedora Linux를 기반으로 하고 있고, Fedora Linux는 매 6개월의 주기로 Major Update 버전을 릴리즈 합니다. 보통 4월과 10월(넷째 주 화요일)에 릴리즈 되며, 13개월 동안 해당 버전을 지원합니다. 예를 들어 Fedora 43이 공실 릴리즈가 출시되면, 그 보다 두 단계 낮은 Fedora 41의 지원이 종료되는 루틴입니다. 

패키지 업데이트는 수시로 등록되며, Kernel 의 경우에도 대략적인 주기는 없습니다.  따라서, Fedora를 사용하는 사용자들은 매 6개월마다 버전을 업데이트하고, 일주일에 한 번 정도만 system 업데이트를 하면 큰 문제없이 가장 최신 버전으로 시스템을 유지 관리할 수 있습니다.  Asahi Linux를 처음 사용하시는 분들이라면 참고하시기 바랍니다.

자 그럼, 이번 올라온 Kernel 7.0에 대한 소식 어떤 내용들이 소개되었는지 살펴 보도록 하겠습니다. 

첫 번째는 설치 프로그램(Installer) 업데이트 및 자동화에 대해 것 입니다.  
Asahi Linux를 mac에 설치하려면, curl | sh 명령을 이용하여 설치를 합니다. 이 명령은 설치에 필요한 python 코드와 m1n1 부트로더, 그리고 복잡한 설치로직이 포함된 거대한 번들을 CDN으로부터 가져옵니다.  과거에는 개발자가 이 설치 패키지를 일일이 수동으로 빌드하고 검증하여 서버에 등록해야 했습니다. 이 과정이 번거롭고 시간이 걸리다 보니, 설치 프로그램이 2024년 6월 버전에 머물러 있는 등 방치되는 문제가 있었습니다. 시스템 라이브러리와 커널은 6.18, 6.19 등으로 계속 최신화되는데,  설치 프로그램 속의 디바이스 트리(Devicetree)는 구형이다 보니, 최신 커널과의 불일치로 부팅 실패등의 부작용이 발생하곤 했습니다. 하지만, 이제 Github Workflow를 통해 자동화가 도입되어, 개발자가 코드만 수정하면 자동화 도구가 Python 코드를 관리하고, m1n1을 빌드하여 최신판을 즉시 서버에 개시합니다. 덕분에 개발자의 수고는 줄어들고, 사용자는 늘 최상의 설치 환경을 제공받을 수 있게 되었다고 설명합니다. 

두 번째 섹션은 ALS(조도센서: Ambient Light Sensor)와 그에 필요한 Firmware 관리 방식 변화에 대한 내용입니다. 
mac의 광센서는 단순히 화면 밝기를 조절하는데 그치지 않고, 주변 색온도를 감지하여 그에 맞춰 화면의 색감 자체를 맞추는 "True Tone" 기능을 수행하는 기반을 지원합니다. True Tone 기능은 정밀한 측정이 선행되어야 하며, 이를 효율적으로 처리하기 위해 CPU가 아닌 AOP(Always-On Processor)라는 별도의 저전력 Chip이 역할을 분담합니다. 광센서에서 출력되는 row 데이터는 교정 과정 거쳐야만 정확한 값을 얻을 수 있는데, 문제는 이 교정 펌웨어가 저작권 문제로 배포판에 포함될 수 없다는 점입니다. 결국 사용자의 mac 내부에서 바이너리를 직접 추출해야 하는데, 이 과정은 EFI 파티션을 건드리는 등 매우 까다로운 작업이 수반됩니다. Asahi Team은 이를 해결하기 위해 펌웨어 패키지 재빌드(Building vendor firmware package) 기능을 추가했다고 합니다. 결론적으로 사용자가 직접 관련 지식과 기술을 알아야 할 수 있었던 작업을 설치 과정에서 자동으로 처리되도록 했다는 내용입니다.

 
세 번째 섹션은 유휴상태(Idle) 상태에서의 전력 소모 개선과 관련된 것입니다. 
Apple Silicon의 최대 강점인 저전력 설계는 PMP(Power Management Processor)가 핵심적인 역할을 합니다. 그 동안 Pro, Max, Ultra 칩을 탑재한 고사양 mac에서 Asahi Linux를 구동할 경우, 대기 상태(Idle State) 에서 조차 전력이 많이 소모되는 문제가 내제되어 왔었습니다. Apple Silicon SoC에서 전력을 관리하는 두 가지 핵심 장치는 PMGR(Power Manager)와 PMP 인데, PMGR은 SoC의 각 내부 Domain 에 전원을 물리적으로 여닫는 스위치 역활을 수행하며, PMP는 각 하드웨어 블록들로 부터 전원 상태 보고를 받아, 데이터 경로인 Apple Fabric의 전력과 클럭을 조절하는 두뇌 역활을 수행합니다. 개발자 chaos princess는 PMP가 하드웨어 블록들로부터 보고를 받을 수 있도록 드라이버를 개발했고, 그 결과 M1 Macbook Pro 기준으로 0.5W 즉, 유휴 소모전력의 20%를 줄여 배터리 사용시간을 더 늘릴 수 있게 되었다고 합니다. 현재는 검증 단계라 기본 비활성화 상태이지만, 향후 고사양 모델 사용자들이 베터리 타임이 늘어날 것으로 기대됩니다.

다음 네 번째로는 일부 사용자들이 지속적으로 문제를 제기해 온 Bluetooth 오디오 끊김 문제에 대한 것입니다. 
WiFi와 Bluetooth가 모두 동일한 2.4GHz 대역을 사용하는 상황이라면 같은 공간에서 서로 간섭을 일으킬 가능성이 큽니다. WiFi를 5GHz 급으로 사용하는 사용자들은 이런 문제를 비켜갈 수 있지만, 동일한 주파수 대역을 사용할 수밖에 없는 상황에서는 피해 갈 수 없는 문제입니다. 이를 근본적으로 해걸할 수 있는 방법은 WiFi 와 Bluetooth를 개별 device가 아닌 통합 Device로 만들고 통합적으로 관리하는 것입니다. 즉, 상황에 따른 서비스 우선순위 방식을 사용하면 해결할 수 있습니다. Bleutooth 특히 Audio와 같이 끊김 없는 서비스를 해야 하는 경우는 이벤트성으로 발생하는 Bluetooth 기기 처리와는 다른 방법을 사용해야 합니다. 애플은 탑재된 Broadcom Chip을 제어하기 위해 독자적인 방식을 사용하는데, 이 또한 비공개이기 때문에, Asahi Linux에서는 macOS를 사용할 때와 동일한 수준의 제어를 할 수 없었습니다. 하지만, 이제 Linux kernel 에 Broadcom 전용 명령어를 추가하여 Bluz 에서 높은 우선 순위를 설정하는 방법으로 오디오 처리에 대한 우선순의를 높힐 수 있도록 명령을 내릴 수 있게 되었고, 끊김없는 Bluetooth Audio를 사용할 수 있게 되었다고 합니다. 

다섯 번째 섹션에서는 DCP(Display Control Processor)와 관련된 내용입니다. 
모니터에 표시될 화면 구성을 GPU가 하더라도, 이를 실제 모니터에 뿌려주는 최종 단계는 GPU가 아니고 DCP(Display Control Processor)가 담당합니다. GPU는 매 프래임 화면을 구성한 후, 약속된 Format으로 DCP로 보내면 DCP가 특정 포트에 연결된 모니터에 표시를 하게 됩니다.  mac, 특히 내장 디스플레이를 갖추고 있는 MacBook이나 iMac 같은 모델은 ProMotion이라는 기능을 제공하는데, 이는 일반적으로는 가변 주사율(VRR, Variable Refresh Rate) 기능과 유사한 apple의 비즈니스 용어 입니다. 물론, 외장 모니터에 대해서도 VRR 기능을 지원할 수는 있는데, 모니터가 Adaptive Sync(Free Sync) 기능을 지원해야 합니다. 

리눅스 드라이버를 개발할 때, 디스플레이와 관련된 특정 매개변수를 0으로 설정하는 코드가 있었는데, 당시 개발자들은 이것이 단순히 전원을 켜는 순서(Power Sequence) 중 하나라고 생각했다고 합니다. 그런데, 후에 이 매개변수가 0과 0x3000000 사이에서 값 사이에서 변하는 것을 발견했고, 0x3000000이 16진수 고정 소스점 방식으로 48Hz를 의미하는 것이라는 알게 되면서 이 설정값이 전원 버튼이 아니라 VRR의 최소 주사율을 결정하는 값이었다는 것을 알게 되었다고 합니다. 따라서, 이 값을 조정하면 가변 주사율을 구현할 수 있기는 하나 VESA 표준에서 VRR은 화면의 깜박임이 없이 VRR을 켜고 끌 수 있어야 한다고 규정하고 있는데, Apple의 DCP는 VRR 상태를 바꿀 때마다 반드시 화면을 재설정하는 모드 셋(Modeset)을 해야 하고, 이 때문에 리눅스 표준 API인 KMS를 통해 정식으로 VRR을 실현할 수 없다는 것을 알게 됩니다.

따라서, 현재는 가장 높은 주파수로 고정을 하고 있는 상태이며. 이 문제를 해결하기 위해 논의가 진행 중이라고 합니다. DCP와 관련해서는 GPU와의 통신에서 대역폭 및 에너지 소모 비용을 줄이기 위한 tiling & compressed frame buffering을 사용할 수 있는데, 이 부분도 아직은 완벽하게 구현되어 있지 않은 상태입니다. 

 
여섯 번째 섹션은 Apple Silicon의 독특한 오디오 하드웨어 구조와 이를 리눅스 표준에 맞게 구현하는 것과 관련된 내용입니다. 
mac의 내장 스피커는 일반 PC와는 달리 관련된 하드웨어의 최대 성능치를 발휘하도록 처리하고 있는데, 이때 스피커가 과열되어 타버리는 불상사를 방지하기 위해 매우 정교한 시스템이 작동한다고 합니다. 즉, 앱프 칩이 스피커에 흐르는 전압과 잔류의 세기를 실시간으로 측정하여 SoC에 보고하면, 이 데이터를 받아 스피커의 물리적 특성을 바탕으로 스피커 코일의 온도를 계산하고 이를 통해 실시간 출력 제어를  하는 메커니즘입니다. 또한, 여러 개의 앰프를 연동하기 위해 'OR 논리 회로'와 유사한 방식을 사용하는데, 데이터 충돌을 방지하기 위해 대기 앰프의 신호를 낮게 유지하는 'Bus Keeper' 회로가 쓰입니다. Asahi 팀은 이 설정을 제어할 수 있는 새로운 범용 API를 직접 구현했으며, 이는 Kernel 7.1에 정식 포함될 예정이라고 합니다. 

 
일곱 번째 섹션은 mac의 Custom Chip에 대한 성능 향상과 관련된 내용입니다. 
Chip Vender들은 USB-C, 스피커, 헤드폰 젝 등을 지원하기 위해 Apple이 특별히 요구한 사양의 Custom Chip들을 제공하고 있습니다. 따라서, 이들 Chip들의 데이터시트는 일반적으로 공개되어 있지 않는데, 그중 헤드폰 잭을 지원하는 칩인 CS42L84에서 macOS보다 더 높은 성능을 이끌어 낼 수 있는 방법을 알아냈다고 합니다. macOS에서는 48kHz와 96kHz로만 이 칩을 작동시키는데, 일반 상용 CS42L42 칩의 데이터 시트를 분석한 결과, 레지스터는 비록 다르지만 특정 rate를 설정하는 값 자체는 동일하다는 점을 발견하게 되었다고 합니다. 이를 이용하면 macOS에서는 지원하지 않는 44,1, 88,2, 176.4, 및 192kHz의 값을 설정할 수 있어 하드웨어가 지원하는 최고 수준의 192kHz/24bit 고해상도 음원을 지원할 수 있게 됩니다. 이 패치 또한 Kernel 7.1에 정식으로 포함시킬 예정이라고 합니다.  물론, true 192kHz의 음원을 즐기려면, 음원 - Pipewire - wireplumber - H/W 설정이 모두 적절히 설정 되어야만 되는 부분이기는 합니다. 
 

여덟 번째 내용은 M3 지원과 관련된 것입니다. 
현재까지 PCIe, 키보드 및 트랙패드, SMC 기반의 RTC 및 reboot 컨트롤러, 그리고 내장 저장장치인 NVMe 컨트롤러의 접근 권한을 확보했다고 합니다. 현재 수준은 alpha 단계로 기본적인 하드웨어들을 인식하고 제어할 수 있는 수준이라고 하는데, 일반 사용자들이 M1/M2처럼 curl | sh 로 설치할 수 있는 단계는 아니지만, 곧 M3를 지원할 수 있게 될 것이라고 언급하고 있습니다. 
마지막으로는 Fedora 44 릴리즈 시점과 그리 차이 나지 않게, Asahi Linux도 44 버전을 공식 릴리즈 할 것이라고 합니다. 

- - - - - - - -

이번 Kernel 7.0과 관련된 진행 보고서는 그 어느 때의 보고서 보다, 내용이 길고 많은 부분을 다루고 있는 것 같습니다.
아직은 M1/M2에서도 Thunderbolt와 DP-alt Mode 지원이 정식으로 제공되지 않고 있습니다. Fairydust Kernel branch를 통해 그 가능성을 보여 주었고, 머지않아 정식 릴리즈에서 이 기능들은 탑재될 것으로 예상이 됩니다. 아울러, M3 지원이 순조롭게 진행되고 있다는 것은 사용자들의 기대감을 높이는 요소입니다.  

Ashi Team의 노력과 열정에 박수를 보내며,
앞으로의 성과에 대해서도 응원을 보냅니다.