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

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

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

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

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

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

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


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

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

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

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

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

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


person paxdiablo    schedule 12.01.2009    source источник
comment
Я могу сказать вам, что определенно неправильно: писать Линусу по почте.   -  person eckes    schedule 03.05.2015


Ответы (6)


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

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

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

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

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

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

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

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

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

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

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

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

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

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

person Blaisorblade    schedule 12.01.2009

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

person Chris Young    schedule 12.01.2009
comment
Кажется, все в порядке, но нет явного входа в интересующую область, а это значит, что я, наверное, буду доставать самого Линуса :-). - person paxdiablo; 12.01.2009
comment
Нет, вы должны отправить письмо в список рассылки ядра Linux, см. раздел 5, параграф 2. - person Chris Young; 12.01.2009
comment
Я отправил драйвер ядра, и он был принят через список рассылки LKML. это, наверное, лучший способ сделать это - person Hasturkun; 12.01.2009
comment
Ах, я не смог найти раздел 5 (там всего 3 раздела), но я вижу, вы имеете в виду раздел 1, часть 5. Большое спасибо. Я попробую. - person paxdiablo; 12.01.2009
comment
Да, прости. Раздел 1, подраздел 5, пункт 2. :) - person Chris Young; 12.01.2009

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

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

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

person Diomidis Spinellis    schedule 12.01.2009

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

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

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

person shodanex    schedule 12.01.2009

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

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

person OIS    schedule 12.01.2009
comment
Особенно мне нравится раздел WhatNotToDo (вы все идиоты!). Надеюсь, это позволит избежать каких-либо первоначальных проблем. - person paxdiablo; 12.01.2009
comment
И GettingFlamed, с которым, вероятно, сталкивается большинство новых отправителей. :) - person OIS; 12.01.2009

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

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

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

person Blaisorblade    schedule 13.01.2009
comment
Я бы ни в коем случае не предлагал разработчикам, что это ошибка, это явно улучшение - я принял ваш предыдущий ответ из-за другой информации в нем. Во всяком случае, теперь он доступен на LKML, чтобы мир мог его увидеть и обсудить. Вернулось одно сообщение, и оказалось, что DB2 также действует аналогично WAS, надеюсь, выиграют не только IBM. - person paxdiablo; 14.01.2009
comment
Извините, я упустил из виду эту очень важную деталь. - person Blaisorblade; 14.01.2009