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

Question

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

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

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

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

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

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

---

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Особенно, опустить такие утверждения:

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

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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