Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Kernel CI does not build drm-kmod, so LinuxKPI header regressions reach main green

Abierto
  • ¿Algo no está bien?
#201 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
c, github-actions
Área
ci-cd, operating-systems

Línea de trabajo

Start with the kernel PR workflow and the drm-kmod build step in nextbsd-kernel-extensions, which the issue identifies as the existing reference. Check how the workflow can use the just-built kernel and restrict the check to PRs touching sys/compat/linuxkpi/. Done means those changes trigger a drm-kmod build (or the described header-check stopgap) and unrelated PRs do not incur the extra build.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:graphics

What happened

nextbsd/nextbsd-kernel#198 merged with all checks green and immediately broke the drm-kmod build in nextbsd-kernel-extensions — every amdgpu object failed with redefinition of 'resource'. Fixed in nextbsd/nextbsd-kernel#200; this issue is about the gap that let it through.

The gap

Patches under patches/ can modify sys/compat/linuxkpi/common/include/linux/*.h. Those headers have two consumers:

  1. the kernel itself — built by kernel (amd64) / kernel (arm64), and
  2. drm-kmod, built in a different repository (nextbsd-kernel-extensions) against the kernel's installed headers.

Only the first is a required check on a kernel PR. A change that is fine for the kernel but breaks the LinuxKPI include graph is invisible until someone opens an unrelated extensions PR — which is exactly how this surfaced.

That class of bug is easy to hit here: LinuxKPI has types that deliberately shadow FreeBSD ones (struct resource in <linux/ioport.h> vs sys/rman.h), so any new sys/*.h include in a LinuxKPI header can reorder definitions for consumers the kernel build never exercises.

Suggested fix

Add a check to the kernel PR workflow that builds drm-kmod against the just-built kernel — the same step nextbsd-kernel-extensions already runs — gated to PRs whose diff touches sys/compat/linuxkpi/, so the cost lands only on the PRs that can trigger it.

A cheaper stopgap, if the full build is too slow to gate on: compile a single translation unit that includes <linux/mfd/core.h> (which pulls platform_device.h then ioport.h) plus the other LinuxKPI headers with shadowing types. That would have caught this specific regression in seconds.

Related

  • nextbsd/nextbsd-kernel#200 — the fix
  • nextbsd/nextbsd-kernel#198 — the PR that introduced it
Lenguaje dominante
C
Estrellas
12
Forks
3
Merge medio
7 h 1 min
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextbsd/nextbsd-kernel

Todos los issues de nextbsd/nextbsd-kernel

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.