https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#include-patch-in-the-subject

все еще проталкиваю мелкое исправления в ядро, и наткнулся на претензию на которую не знаю, как ответить:

Кинь ссылку, иначе контекст не понятен.

но я не понимаю, что за префикс??

Может иметься ввиду [PATCH], как сказали выше.

Или может речь про то, что после [PATCH] обычно указывают названия изменённых компонент, пример: leds: tca6507: do not set GPIO names. В этом случае можно посмотреть как другие люди оформили патчи к файлам, которые изменил ты, и сделать аналогично.

вот ссылка, https://lkml.org/lkml/2020/10/28/921 ...

сейчас попробую найти на lkml что-то похожее

p.s. или наоборот, префикс не нужен.... так ведь нет.
p.p.s. последняя переписка на lkml почему-то не отображается :-\

и еще один вопрос, может, Вы знаете, так вести переписку, чтобы она отображалась на lkml? по-идее, с git send-email ... , или можно и из почтового клиента?

// сейчас попробую с почтового клиента

Мини-ревью:

вот ссылка, https://lkml.org/lkml/2020/10/28/921 …

• Сделай git log drivers/net/ethernet/microchip/lan743x_ethtool.c и посмотри заголовки коммитов, нацеленных на конкретно этот файл. Они начинаются lan743x:, и тебе надо сделать так же. Видимо под префиксом именно это имелось ввиду.
• Это не обязательно, но я бы добавил в описание коммита кусок из dmesg, в котором видно NULL pointer dereference вместе со всем стектрейсом. Это поможет другим людям, напоровшимся на этот же баг, найти твой патч поисковиком в интернете.
• Раз ты исправляешь баг, то надо добавить тег Fixes:, который указывает на коммит, который этот баг внёс. Если баг в коде изначально, то укажи коммит, который этот код добавил.
• Если код с багом успел попасть в релизы ядра (номерные кроме -rc*), то необходимо добавить тег Cc: stable@vger.kernel.org, чтобы мейнтейнеры стабильного и LTS-ядер этот патч подцепили своими скриптами и добавили в следующий x.y.Z патч.

и еще один вопрос, может, Вы знаете, так вести переписку, чтобы она отображалась на lkml? по-идее, с git send-email … , или можно и из почтового клиента?

Сами патчи лучше слать только из git send-email, так как многие почтовые клиенты портят форматирование. Отвечать же можно из любого клиента, который может слать plain text.

Чтобы ответить всем, кто изначально был в Cc: (включая сам список рассылки), надо жать на кнопку «Ответить всем»/«Reply to all»/etc. Во всех почтовых клиентах эта кнопка есть.

Небольшое дополнение:

Когда будешь отправлять обновлённый патч, то не забудь указать, что это новая версия: [PATCH v2]. И добавь в него список изменений. Опять же, посмотри как это делают другие люди.

ок, понял, спасибо большое! :)

отослал, https://www.lkml.org/lkml/2020/11/1/349
но забыл в описание истории v2 внести «ревьювера» Jakub Kicinski :-\

Сколько пердолинга на ровном месте, это всё где то описано хотя бы в вольной манере или как тут из уст в уста передаётся?

Когда будешь отправлять обновлённый патч, то не забудь указать, что это новая версия: [PATCH v2]

вручную указывать не надо, для этого есть команда git: git send-email --annotate -v2 ...

Сколько пердолинга на ровном месте, это всё где то описано хотя бы в вольной манере или как тут из уст в уста передаётся?

Про префикс должно стать очевидно после просмотра git log. Плюс, практически во всех более-менее крупных проектах принято в заголовке коммита писать <имя компонента>: краткое описание, ядро линукса тут вообще не уникально.

Про кусок лога в описании коммита - это вообще не требование. Я написал почему хорошо бы это сделать.

Остальное подробно описано в документации по ссылкам.

Сколько пердолинга на ровном месте, это всё где то описано хотя бы в вольной манере или как тут из уст в уста передаётся?

это для того чтобы в ядре не появлялось шлака

а описано все тут: https://www.kernel.org/doc/html/latest/process/submitting-patches.html

я, просто, слегка параноик и не хотел, чтобы были какие-то большие косяки

спасибо :) буду иметь в виду

Рекомендую потренироваться по инструкции https://git-send-email.io/

обязательно поиграюсь, спасибо! :)