Linux Kernel Developers Considering Removal Of KGDB Debugging Functionality
리눅스 커널 개발자들, KGDB 디버깅 기능 제거 검토
Peter Zijlstra가 Linux 커널에서 KGDB를 제거하는 패치를 제출했습니다. KGDB가 NMI 문맥과 시간 관리, 워치독, 브레이크포인트 처리에 문제를 일으킬 수 있으며 QEMU의 GDB 서버로 대체할 수 있다는 주장입니다. 하드웨어 의존 디버깅에는 대안이 충분한지 의견이 갈립니다.
- 주제
에디터 노트
제거 근거로 제시된 NMI 문맥 정체와 시간 관리 및 워치독 문제는 단순히 사용 빈도만 따진 주장이 아닙니다. 반면 QEMU GDB 서버는 가상화가 가능한 환경을 전제로 하므로, 실제 임베디드 장치를 디버깅하는 경우까지 같은 방식으로 대체할 수 있는지는 별도 쟁점으로 남습니다. 댓글에는 KGDB의 드문 유용성을 인정하는 경험과, 장치 전달이나 시리얼 출력, printk를 대안으로 보는 의견이 함께 있습니다. 다만 댓글만으로 대안이 모든 장치와 개발 절차에 적용되는지는 확인되지 않습니다. 현재는 제거 패치가 제안된 단계이며, Kconfig에서 먼저 끄자는 절충안도 언급됐습니다.
AI 요약
Peter Zijlstra가 Linux 커널에서 KGDB 지원을 완전히 제거하는 패치를 제출했습니다. Zijlstra는 가상화 환경에서 QEMU의 GDB 서버를 사용할 수 있어 KGDB를 유지할 이유가 적다고 주장합니다. KGDB는 NMI 문맥에 머무르며 시간 관리 코드를 망가뜨리거나 워치독을 작동시킬 수 있고, 코드 패치와 브레이크포인트 처리에도 문제가 있다고 설명했습니다. 한편 KGDB를 먼저 Kconfig 옵션으로 비활성화한 뒤 몇 차례 커널 릴리스 후 제거하자는 제안도 나왔습니다.
Reddit 반응
- @james_pic — 나이가 들었고 제대로 살피지 못했나 봅니다. 예전에 Linus가 커널에는 디버거가 필요 없고 printk를 쓰면 된다고 말하던 때를 기억합니다. 그가 KGDB를 받아들였다는 걸 몰랐습니다. 거의 20년 전 일이기도 하네요. 그래도 여전히 그렇게 생각하는 듯합니다.
- @chibiace — 그가 받아들였다는 걸 몰랐습니다. 그에게 이런 일이 계속되는 것 같네요. 기업들의 압력이 있었을까요?
- @BashfulMelon — 동료들과 타협한 사람을 두고 기업 음모라고 하나요?
- @ohYuhtBoutMagine — 좋은 엔지니어의 표지는 새로운 정보와 피드백을 받아들이는 태도입니다.
- @gwillen — 거의 쓰이지 않는 데다 더 나은 방법이 있으니 KGDB를 쓰지 않는다는 말로 들립니다. 커널에 디버거를 붙여 본 적은 없지만 그럴듯합니다.
- @ilep — 가상화에 접근할 수 없는 경우가 커널 내부 디버깅 기능의 주요 장점이라고 봅니다. 예를 들어 임베디드 장치 드라이버를 개발할 때입니다. 장치에 용도의 시리얼 포트가 있으면 컴퓨터에서 연결해 디버깅할 수 있습니다.
- @Lenticularis19 — KGDB는 묘합니다. kprobes 같은 추적 기능을 쓰다가 가상 머신이 멈춘 이유를 궁금해한 적이 있습니다. GDB를 연결해 보니 kprobe 경로로 가지 않고 KGDB를 기다리며 트랩에 걸려 있었습니다. KGDB가 활성화된 걸 잊고 있었습니다.
- @blind99 — 아쉽습니다. 쓰기 어렵고 느리지만 가끔 유용합니다.
- @anh0516 — 화면이 아니라 시리얼 포트로도 메시지를 출력할 수 있습니다.
- @zerosign0 — 드라이버에도 KGDB가 유용한가요? 드라이버 개발이 어떻게 이뤄지는지 잘 모르겠습니다. 먼저 커널 모듈로 만들고 안정되면 메인라인에 넣나요? amdgpu나 PSR 같은 드라이버 변경에서 생기는 문제는 어떻게 다루나요?
원문: Phoronix / 번역·요약: Trawling