Kernel CI does not build drm-kmod, so LinuxKPI header regressions reach main green
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 52/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- c, github-actions
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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:
- the kernel itself — built by
kernel (amd64)/kernel (arm64), and - 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
- 主要言語
- C
- スター
- 12
- フォーク
- 3
- 平均マージ
- 7時間 1分
- マージ済み PR（30日）
- 7
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
nextbsd/nextbsd-kernel のほかの issue
-
area:bluetooth bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
nextbsd/nextbsd-kernel#236 ·
メンテナーはふだん 1 日以内に返信
-
area:vm bug
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
nextbsd/nextbsd-kernel#226 ·
メンテナーはふだん 1 日以内に返信
-
area:network enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
nextbsd/nextbsd-kernel#53 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
nextbsd/nextbsd-kernel#254 ·
メンテナーはふだん 1 日以内に返信
-
linsysfs: create DRM sysfs nodes for platform-bus GPUs so Linux libdrm finds vc4/v3d on the Pi 5オープンarea:linux area:rpi5 enhancement
難易度 4/5 3〜5日 初心者へのやさしさ 47/100
nextbsd/nextbsd-kernel#248 ·
メンテナーはふだん 1 日以内に返信
nextbsd/nextbsd-kernel の issue をすべて見る
似ている issue
-
native-cpu: -Wreturn-type in skainet_row_threads.c:150 (worker fn has no return)対応中かも @Doomguy-BFG9000 が今日担当しました。 オープンgood first issue size:xs skill:native
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
SKaiNET-developers/SKaiNET#1358 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
I/O internal correctness medium priority rt_lib
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 64/100
libsdl-org/SDL#16539 ·
メンテナーはふだん 1 日以内に返信
-
git-workflow task-4
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信