A patch posted to the Linux kernel mailing list has put KGDB — the in-tree kernel debugger that has shipped since Linux 2.6.26 in 2008 — on the table for removal, according to a report from Phoronix.
KGDB pairs with the GNU Debugger to let developers step through kernel code much as they would a user-space program. Its defining characteristic, and the likely reason its user base has thinned, is that it requires a second physical machine tethered to the target over a serial or network connection. The two-computer arrangement made it a natural fit for embedded and bring-up work two decades ago, but it sits awkwardly in modern data-centre workflows where kernels run inside containers, virtual machines and remote nodes.
The practical alternative that has grown up around it is kgdboc — "kgdb over console" — which routes the debugger through a serial console or similar transport rather than a dedicated second box. The distinction matters: KGDB as a subsystem is the candidate for deletion, while the transport mechanism and the companion kernel debugger KDB are separate concerns, and KDB has been explicitly kept out of scope in the discussion. Any observer reading the patch thread should not assume the entire low-level debugging stack is being ripped out at once.
What is at stake. KGDB is not widely used in recent years, which is precisely why removal is being floated. But "not widely used" is not "unused," and kernel removal proposals of this kind would almost certainly not land without further discussion on the mailing list. As of the Phoronix report, the proposal remains at the discussion stage rather than an accepted decision — developers who depend on KGDB for hardware bring-up, driver development or long-cycle embedded targets still have a window to weigh in before any fate is sealed.
Practical impact for operators and SREs. For cloud and container operators, infrastructure teams and site-reliability engineers, the direct day-to-day impact is likely to be small: almost nobody debugs a production node with a serial cable and a second laptop. The relevance is more about knowing what the replacement stack already is. Kernel tracing via ftrace, sampling and profiling through perf, dynamic instrumentation with eBPF, crash dump analysis with kdump and crash, and the built-in GDB stubs exposed by hypervisors such as QEMU all cover the ground that KGDB used to occupy — and they work on a single machine or over the network without extra hardware. Teams that have inherited a KGDB-based runbook, or that still carry legacy embedded systems in their fleet, are the ones who should check whether their tooling assumptions still hold.
The story also matters as a signal about how the kernel community maintains its own surface area. KGDB's 2008 arrival predates containers, eBPF and the current observability toolchain by years; a subsystem that once filled a genuine gap can quietly become a maintenance burden once the ecosystem routes around it. Watching which legacy debugging facilities get proposed for removal — and how the community argues about it — offers a useful read on where kernel diagnostics are headed.
What comes next. The patch exists as a proposal, and the mailing list conversation will determine whether it advances, is narrowed in scope, or stalls. Developers and toolchain maintainers with a stake should follow the LKML thread directly; Phoronix's coverage continues to serve as the running summary of where the discussion stands.
據 Phoronix 報道，一則提交至 Linux kernel mailing list 的 patch，令 KGDB —— 這個自 2008 年 Linux 2.6.26 起一直隨核心發佈的 in-tree kernel debugger —— 面臨被移除的可能。
KGDB 與 GNU Debugger 配合使用，讓開發者可以像逐步執行用戶空間程式一樣，逐步執行核心代碼。其最顯著的特徵 —— 亦很可能是其用戶群日漸萎縮的原因 —— 在於它需要第二部實體機器，透過 serial 或網絡連接繫結至目標機。這種雙機配置在二十年前非常適合嵌入式及系統 bring-up 工作，但放諸今日以 container、virtual machine 及 remote node 運行核心的現代數據中心工作流程，就顯得格格不入。
圍繞它發展出來的實用替代方案是 kgdboc —— 即「kgdb over console」—— 它透過 serial console 或類似傳輸介面來接入 debugger，而無需獨立的第二部機器。這個區別相當重要：作為 subsystem 的 KGDB 是被刪除的候選對象，而傳輸機制及配套的核心 debugger KDB 則屬另一回事，討論中已明確將 KDB 排除在外。任何閱讀該 patch 討論串的人士，不應假設整個低層除錯架構會被一次性移除。
利害所在。 KGDB 近年使用並不廣泛，這正是今次提出移除的原因。但「使用不廣泛」並不等於「無人使用」，此類核心移除建議幾乎肯定會先在 mailing list 上經過進一步討論才會落實。截至 Phoronix 的報導，該建議仍處於討論階段，並非已接納的決定 —— 依賴 KGDB 進行硬件 bring-up、驅動開發或長周期嵌入式目標的開發者，仍有機會在命運定案前表達意見。
對營運及維護人員和 SRE 的實際影響。 對 cloud 及 container 營運商、基礎設施團隊及 site-reliability engineers 而言，日常直接影響相信甚微：幾乎沒有人會用 serial 線及第二部 laptop 去除錯 production 節點。更重要的是了解取代它的工具鏈已經是什麼。透過 ftrace 進行的 kernel tracing、透過 perf 進行的抽樣及 profiling、以 eBPF 實現的 dynamic instrumentation、以 kdump 及 crash 進行的 crash dump 分析，以及 QEMU 等 hypervisor 內建的 GDB stub，均已覆蓋 KGDB 原先佔據的範疇 —— 而且它們只需一部機器或透過網絡即可運作，毋須額外硬件。沿用基於 KGDB 的 runbook，或機群中仍配備舊式嵌入式系統的團隊，正正需要檢查他們對工具的假設是否依然成立。
這則消息同時也是一個信號，反映核心社群如何維護自身的功能範疇。KGDB 於 2008 年登場，比 container、eBPF 及現時的 observability 工具鏈早了數年；一個曾經填補真實空白的 subsystem，一旦整個生態圈繞道而行，便可能悄然成為維護負擔。留意哪些舊有除錯功能被建議移除 —— 以及社群如何就此辯論 —— 可以幫助我們判斷核心診斷技術的發展方向。
下一步。 該 patch 目前只是一項建議，mailing list 上的討論將決定它會否推進、範圍會否收窄，抑或就此停滯。有利害關係的開發者及工具鏈維護者應直接追蹤 LKML 討論串；Phoronix 的相關報導則持續作為梳理討論進度的動態總結。