The kgdboc driver is actually a very thin driver that relies on the underlying low level to the hardware driver having "polling hooks" which the to which the tty driver is attached. In the initial implementation of kgdboc it the serial_core was changed to expose a low level UART hook for doing polled mode reading and writing of a single character while in an atomic context. When kgdb makes an I/O request to the debugger, kgdboc invokes a callback in the serial core which in turn uses the callback in the UART driver.

When using kgdboc with a UART, the UART driver must implement two callbacks in the struct uart_ops. Example from drivers/8250.c:

#ifdef CONFIG_CONSOLE_POLL
	.poll_get_char = serial8250_get_poll_char,
	.poll_put_char = serial8250_put_poll_char,
#endif
  

Any implementation specifics around creating a polling driver use the #ifdef CONFIG_CONSOLE_POLL, as shown above. Keep in mind that polling hooks have to be implemented in such a way that they can be called from an atomic context and have to restore the state of the UART chip on return such that the system can return to normal when the debugger detaches. You need to be very careful with any kind of lock you consider, because failing here is most likely going to mean pressing the reset button.

The kgdboc driver contains logic to configure communications with an attached keyboard. The keyboard infrastructure is only compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the kernel configuration.

The core polled keyboard driver driver for PS/2 type keyboards is in drivers/char/kdb_keyboard.c. This driver is hooked into the debug core when kgdboc populates the callback in the array called kdb_poll_funcs[]. The kdb_get_kbd_char() is the top-level function which polls hardware for single character input.

The kgdboc driver contains logic to request the graphics display to switch to a text context when you are using "kgdboc=kms,kbd", provided that you have a video driver which has a frame buffer console and atomic kernel mode setting support.

Every time the kernel debugger is entered it calls kgdboc_pre_exp_handler() which in turn calls con_debug_enter() in the virtual console layer. On resuming kernel execution, the kernel debugger calls kgdboc_post_exp_handler() which in turn calls con_debug_leave().

Any video driver that wants to be compatible with the kernel debugger and the atomic kms callbacks must implement the mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations. For the fb_debug_enter and fb_debug_leave the option exists to use the generic drm fb helper functions or implement something custom for the hardware. The following example shows the initialization of the .mode_set_base_atomic operation in drivers/gpu/drm/i915/intel_display.c:

static const struct drm_crtc_helper_funcs intel_helper_funcs = {
[...]
        .mode_set_base_atomic = intel_pipe_set_base_atomic,
[...]
};
  

Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in drivers/gpu/drm/i915/intel_fb.c:

static struct fb_ops intelfb_ops = {
[...]
       .fb_debug_enter = drm_fb_helper_debug_enter,
       .fb_debug_leave = drm_fb_helper_debug_leave,
[...]
};