Asahi Linux, UEFI 런타임 서비스로 Apple Silicon PSCI와 CPU 절전 업스트림화 추진
- Apple Silicon 코어는 Linux가 기대하는 EL3을 구현하지 않아 SMC·HVC 기반 PSCI 호출을 할 수 없고, 이 때문에 기존 Apple 전용 cpuidle 드라이버를 업스트림에 넣지 못한 상태임
- Sven은 m1n1 메모리를 펌웨어 영역으로 남기고 UEFI Runtime Service를 PSCI 호출 통로로 쓰는 방식을 구현 중이며, 이를 쓰는 Linux 커널 패치는 RFC로 메일링 리스트에 올라감
- arm64 유지관리자는 업스트림 하드웨어의 전력 관리에 PSCI 사용을 의무화했으며, Asahi의 Apple 전용 deep WFI cpuidle 드라이버는 그 규칙 때문에 다운스트림에 남아 있음
- M4에서는 Apple이 mBoot 단계에서 코어별 state-retention 설정을 잠가 WFI가 코어 상태를 잃고 실행 중인 작업을 크래시시킬 수 있으며, Yurkea가 idle loop 동작을 고르는 커널 명령줄 인자를 추가함
Hacker News 의견들
몇 년 동안 소수 인원이 불안정한 기반 위에서도 여기까지 온 게 대단함. 진행 상황 지켜보는 재미가 있었음.
VA-API는 v4l2-requests와 잘 맞지 않음. VA-API는 코덱별 처리를 미리 하는데 v4l2-requests는 비트스트림에서 파싱한 원본 정보를 드라이버가 받는 방식을 전제함.
Apple이 보안에 들인 노력을 보면 대체 OS를 공식 지원하지 않는 이유도 어느 정도 이해됨.
그래도 Apple Silicon Mac의 대체 OS 실행을 위해 Apple이 상당히 해 둔 일이 있음. Asahi의 Open OS Interoperability 문서가 그 사례임.
M3 Pro MacBook Pro에 언젠가 Linux를 설치하려고 샀는데, 부분 호환에도 이렇게 많은 역공학 작업이 든다는 걸 과소평가했음. iOS 개발 때문에 macOS는 남기겠지만, 브라우저와 Ghostty, 좋은 배터리 시간이면 나머지는 충분함.
문서도 안 내고 Linux 드라이버 개발자도 지원하지 않는 Apple에 수천 달러를 낸 뒤, 무급 자원봉사자가 해결해 주길 기다린 셈이기도 함.
M4에서 하이퍼바이저가 동작한다는 소식이 특히 반가움. 1~2년 뒤 Asahi를 써 볼 생각임.
기능 역공학이 끝난 뒤 전력 관리를 진지하게 다뤘으면 함. 노트북 일상 사용에서는 배터리 시간이 큰 차이를 만들고, Linux는 전용 튜닝 드라이버 부족 때문에 그 부분이 약했음.
그런 튜닝이 기기 수명 안에 이뤄질지는 의문임. 새 모델은 아직 기능이 다 갖춰지지 않았고 Apple의 오픈소스 무관심도 희망적이지 않음.
Apple의 지원 기간이 기기 수명만큼 길면 Asahi가 꼭 필요하지 않을 수도 있음. 그래도 16GB M1이나 M1 Pro, Max, Ultra는 아직 여러 해 쓸 만하고, Intel Mac은 이제 마지막 macOS를 받은 것으로 보임.
전력 효율만 보고 Apple 하드웨어에 Linux를 쓰려는 건 아님. 디스플레이와 트랙패드 품질, 폼팩터, 노트북의 큰 메모리 용량 때문에 Asahi를 쓰고 싶음.
Intel과 AMD가 따라잡았다는 말에는 동의하기 어려움. Linux에서 M4 Air나 M4 Max Pro와 견줄 만한 AMD나 Intel 노트북이 실제로 있는지 궁금함.
'몇 년'이면 해결된다는 전망도 낙관적임. Asahi는 2021년 1월에 시작했고 M1은 6년, M2는 4년 전 제품인데도, 10년 뒤에도 반세대 지난 기기의 기능 90% 정도와 macOS보다 덜 다듬어진 상태일 수 있다고 봄.
Asahi는 인상적인 프로젝트지만 Apple M 시리즈에서 Linux를 돌리는 건 가장 복잡한 선택지 중 하나임. 꼭 써야 하는 사람은 많지 않을 것 같음.
LLM이 이런 프로젝트에 크게 도움이 될 수도 있겠지만 자금부터 부족해 보임. 개발자들은 새 Apple Silicon 장비는 물론 토큰 비용도 감당하기 어려울 정도로, 기부와 약정은 출범 뒤 계속 줄었다고 함.