Процесс отладки ядра, отсылки и исправления патчей (истории успеха)

минималистичный дистрибутив, где было бы удобно и быстро «переустанавливать» ядро, не засоряя систему;

Я делал под обычными gentoo и arch, в них меньше всего подводных камней с установкой ядра из гита без создания пакета. Но я пока занимался только драйверами, а для многих даже не нужно свежее ядро, и их можно устанавливать отдельными модулями и даже не перезагружаться.

оформление, отсылка патча;

Лучше всего разделить патч на несколько частей, каждая из которых затрагивает некоторые изменения и может быть применена в идеале независимо от остальных частей или хотя бы по очереди в порядке нумерации. Перед отправкой каждый патч надо проверить скриптом scripts/checkpatch.pl и убедиться, что нет ошибок coding style. Файл патча устроен примерно так:

[PATCH 04/12] подсистема1: подсистема2: заголовок с коротким описанием

Длинное описание

Signed-off-by: настоящее имя <почта>
возможно, другие заголовки типа Acked-by и т.п.
---
Дополнительный комментарий, который не будет включён в коммит, не обязателен.
Выхлопы diff -up

Если патчей несколько, то нужно первым письмом отправить описание всего, заголовок его примерно такой: «[PATCH 00/12] подсистема1: подсистема2: подсистема3: короткое описание». Под подсистемами тут понимается примерное место, куда внесены изменения, например, «ideapad-laptop: », «msi-wmi: » и т.п.

Отправлять нужно в соответствующий мейллист (например, platform-driver-x86 на vger.kernel.org) и мейнтейнеру (смотреть в файле MAINTAINERS).

Если после обсуждения нужно будет что-то изменить, нужно будет отправить всё заново, изменив заголовок (например, изменить «[PATCH xx/12]» на «[PATCH v2 xx/12]»).

Отправлять удобно с помощью «git send-email --compose --thread patches/*.patch», создавать патчи из коммитов в локальной ветке гита: «git format-patch -s -n --subject-prefix='PATCH v4' -o patches origin/master».

qemu/uml? (uml потенциально подходит, т.к. дело на данный момент не в драйвере);

Не специалист, но когда использовал для написания модулей uml, некоторые падения в госте вызывали и падения хоста тоже, что было не очень удобно.

git clone https://linux.org/... чтобы стянуть необходимый минимум (без истории, только linux-next);

git clone --depth

что соблюдать, чтобы патч был принят/воспринят.

http://www.kernel.org/doc/Documentation/SubmittingPatches

Кто-нить реально проходил эти шаги до победного конца?

У меня порядка 10 принятых патчей. Многое зависит от подсистемы, с которой ты работаешь. Где-то нормально реагируют на письма, а где-то кладут с прибором по непонятным причинам.

P.S. Ну и вредные же суки мэинтейнят планировщик. Не отвечают на письма, даже на нормальные патчи. Мой единственный принятый патч к планировщику заметил Олег Нестеров, который занимается совсем другими подсистемами. Если бы не он, наверняка забили бы хуй.

Да, теперь я понимаю Кона Коливаса