Как отправить потенциальный патч на ядро Linux?

У нас есть программное обеспечение, основанное на определенном поведении от другого ( очень общедоступного) приложения, которое теперь изменилось, что делает нашу текущую реализацию работоспособной, но менее оптимальной.

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

К сожалению, это решение - это изменение ядра (относительно простое, но очень сильное воздействие, если мы его заполняем), и у нас нет опыта отправки исправлений ядра для просмотра.

Кто-нибудь из SO действительно представил патч (хотя я был бы признателен за все ответы, я подозреваю, что лучшие из них будут получены от тех, которые прошли через этот процесс, даже безуспешно)? Приняли ли вы его (каковы шансы, что Алан Кокс и др. Висят на SO)?

Каков правильный процесс? Я не собираюсь отправлять письмо Линусу, так как я знаю, что у него есть кадры защитников, которые вы должны пройти до того, как он доберется до него. Как узнать, кто отвечает за конкретный раздел ядра.

Возможно, я слишком оптимистичен в том, что думаю, что мир, о котором никогда не слышал мир, может внести свой вклад, но мне было бы интересно узнать.

РЕДАКТИРОВАТЬ с более подробной информацией:

Это изменение на самом деле не является ошибкой производительности, а улучшением (по моему мнению) для записей учета процесса (в настоящее время), записанных при завершении процесса.

Сервер приложений Websphere (ах, IBM, благословит их маленькие сердца) изменил то, что он делает; JVM обычно выходили регулярно, чтобы их записи были написаны, и мы могли бы использовать их для возврата. Теперь это оставляет JVM, которые лежат в течение нескольких месяцев, а это означает, что данные не доступны своевременно, если мы не заставим WAS регулярно. Почему-то я не думаю, что IBM Software Group собирается исправить свое программное обеспечение для нас:-). В любом случае, я считаю, что это может быть полезной особенностью для других долгоживущих процессов.

В настоящее время записи процесса учета типа 3 записываются, когда процесс завершается, то, что мы рассматриваем, является механизмом для записи записей типа N периодически, пока процесс все еще активен, давая цифры с момента последней записи (или запускается процесс, если это впервые). Приложения обратной связи или приложения контроля производительности могут использовать либо записи типа 3 (полностью без изменений), либо временные записи типа N. Нынешний обходной путь - мониторинг /proc/PID/stat для конкретных процессов, но это ужасный kludge, поскольку он не хорошо интегрируется с ведением реального процесса.

Это может быть не часто (мы будем довольны 24 часами), но это может повлиять на производительность, так как работа, выполняемая в настоящее время только на выходе процесса(), должна выполняться иногда при переключении контекста процесса. Linus et al может не понравиться эта идея, так как это может быть область с высоким ударом кода (даже проверка, если было 24 часа с тех пор, как последняя запись может быть слишком медленной для них).

Тем не менее, спасибо за все ответы до сих пор, я посмотрю, как я пойду. Дайте мне пару дней, и я приму наилучший ответ.

Ответ 1

Прежде всего: сосредоточив внимание на отчете об ошибках производительности и правильном использовании (с повторяемыми критериями), по крайней мере, поможет вам заставить людей беспокоиться о проблеме. Также отправьте патч после тестирования, но будьте осторожны, что ваш большой патч может использовать неправильный подход и что они могут написать лучший. Или это просто может быть здорово, но может потребоваться исправление, чтобы принять, что даже происходит с uber-парнями. И не думайте, чтобы отправить кого-то в частном порядке, но обратитесь к LKML или к соответствующей подсистеме ML.

Я предлагаю вам прочитать все остальные ответы и все применимые материалы, прежде чем обращаться к разработчикам ядра; и читайте также библиографию SubmittingPatches. Они могут быть жесткими, если вы делаете это неправильно. Ярлыки IRC-чата - это хорошее место для вас, потому что они наверняка приветствуют, даже если иногда среда может быть слишком новичкой (не уверен, что меня там не было).

Возможно, я слишком оптимистичен в том, что думаю, что мир, о котором никогда не слышал мир, может внести свой вклад, но мне было бы интересно узнать.

Это не слишком оптимистично; по крайней мере, не по себе. Абстрагируясь от вас (поскольку я не знаю ваших навыков), тем более маловероятно, что ваш патч будет принят без изменений или что он написан в соответствии с правильными навыками. Но на самом деле, если ваш патч адресован меньшему сообществу, это может быть намного проще.

От кого-то, у кого есть некоторый опыт (например, я), перед рассмотрением публикации патча, опишите проблему и почему она влияет на другие приложения. Такие соображения, как "это улучшает нашу производительность", особенно если вы квалифицируетесь (неопределенно) как поставщик, не будете привлекать разработчиков ядра.

В частности, оставьте такие утверждения:

делает нашу текущую реализацию работоспособной, но менее оптимальной.

потому что это купит вам рекомендацию "исправить свой код" сразу большинству читателей.

Если производительность существующего приложения (не написана вами) подвержена влиянию, это отличается. Например, как только Linus незамедлительно обратил внимание на исправление производительности ядра для прикрученного кода, поскольку этот код был частью make, даже если он был горд кодом, который он написал, и тем фактом, что ему не нужно было делать это точное исправление. I.e., вам нужно приложение, которое все заботятся, или решение без недостатков. Итак, такие вещи, как:

поведение от другого (очень часто используемого) приложения

является хорошим, если ваше использование этого приложения не считается необоснованным.

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

Btw, это частичный отчет о моем опыте: https://www.ohloh.net/accounts/Blaisorblade

Если вы хотите, вы можете связаться со мной, чтобы помочь вам напрямую с предлагаемой почтой, и CC меня на обсуждение. Я довольно занят, но я мог бы найти еще некоторое время: -).

Ответ 2

Ну, вы можете попробовать прочитать Documentation/SubmittingPatches в исходном дереве ядра Linux.

Ответ 3

В большом проекте лучший способ получить патч в главном дереве - связаться с человеком, который поддерживает конкретный фрагмент кода. Итак, просмотрите файл Linux MAINTAINERS, чтобы узнать, кто формально является хранителем кода, который вы изменили, а также в репозиторий SCM Linux ядра, чтобы найти разработчиков, которые недавно работали над этим кодом. Чтобы увеличить ваши шансы на получение патча:

убедитесь, что ваш патч легко понять и соответствует существующим стандартам кода и документации,
четко объясните, что ваш патч достигает,
отправьте свои изменения в соответствующем формате (вывод diff -up для Linux),
убедитесь, что патч можно использовать (и работает) на последней версии программного обеспечения (Linux kernel),
включают тестовые примеры, которые демонстрируют как проблему, которую вы решаете, так и то, как исправление исправляет ее, и
не включать в свой код неулокальные (например, форматирование) изменения.

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

Ответ 4

Прочитайте документацию /SubmittingPatches, найдите соответствующий MAINTAINER и, самое главное, узнайте, где происходит обсуждение действительно. Это может быть не в самом списке рассылки ядра, а, возможно, в некоторой подсистеме ML.

Затем подпишитесь на этот ML и отправьте патч как RFC.

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

Ответ 5

Я сам не пробовал отправлять какие-либо патчи ядра, а docs не хватает в этой области.

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

Ответ 6

В EDIT ответ может быть интересным в качестве примера. Я предполагаю, что ваше требование совершенно разумно, но вы правы, что даже тест на контекст-переключатель может быть слишком дорогостоящим. Но поскольку у ядра есть реализация таймера, я не понимаю, почему его нельзя использовать, чтобы этого избежать. Так что, действительно, предлагая запрос на повышение - это самая безопасная ставка. Я удивлен, что предлагать отправить отчет об ошибке вместо патча было настолько хорошим. Вы также можете изменить патч самостоятельно, чтобы сами использовать таймеры, если хотите отправить его, но все же будете готовы к обсуждению:-) Вы даже можете добавить "у нас есть локальное исправление, но он добавляет некоторые тесты на быстрый путь контекстного коммутатора, поэтому исправление привязано для справки, но не должно применяться". Отказ от собственного кода, если он известен как плохой, позволит избежать суровых обзоров патча.

Альтернативой является запуск некоторых эталонных тестов и доказательство того, что нет никакого эффекта, но если таймеры жизнеспособны, код будет отклонен в любом случае или попытаться самостоятельно решить проблему таймера (что-то лучше может существовать). Найдите те тесты, которые они используют для планировщика ядра; посмотрите "последние" потоки о патче CFS Ingo (или Kolivas?) и возьмите их тесты.

О поддержке разработчики ядра не будут заботиться о "Websphere App Server" сами по себе, если это необоснованные вещи, даже не финансируемые IBM. Но с моим ограниченным знанием ситуаций, закрытие JVM периодически не имеет смысла, это, по-видимому, просто способ бумаги по поводу утечки/нестабильности памяти, поэтому текущее поведение должно поддерживаться.