Сделаем код чище: Что можно исправить в ядре Linux

[@Ununtrium]

Насколько мощная машина нужна для сборки ядра в приемлемое время?

[@andreili]

На стационарнике i5-3470 в 5 потоков собирается минут за 10. Но у меня все необходимое включено в ядро, без модулей :)

[@splav_asv]

Если модули лишние поотключать — любой не нетбук до 5 лет выдержки.
У меня на A10-5850 в 6 потоков —
real 3m25.969s
user 11m33.297s
sys 0m45.940s
Но я думаю в 2.5 реально уложиться — еще много всего не выкинул лишнего из модулей, да и диск очень старый.

[@maksqwe]

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

[@RPG]

  /* make debug message */
  msg[0] = '\0';
  for (j = 0; j < i; j++) {
      snprintf(str, 128, " %02X", buf[j]);
      strcat(msg, str);
  }

Алгоритм маляра Шлемиэля даже в ядре? Хотя это скорее всего никому не нужный драйвер. Одно дело если бы такая ошибка была в fs/ и другое — в каком-то драйвере, которым пользуются только экстремалы.

[@andy_shev]

Алгоритм маляра Шлемиэля

Это 5! Не слышал раньше.

[@tagir_valeev]

Почитайте Джоэля, местами очень познавательно :-)

[@jcmvbkbc]

--git-min-percent=67

Это хорошо, да. А то, бывает, поправишь где-нибудь три строчки, а любители get_maintainer.pl начинают тебя после этого в cc: включать.
В списке рассылки qemu-devel однажды поднималась эта тема, с пожеланиями включить --no-git-fallback по умолчанию.

[@googol]

Не забываем патч прогнать через checkpatch.pl

[@blueboar2]

А это оказывается кто-то так выводит MAC адрес! Что ж, мы с лёгкостью можем использовать специальное расширение спецификатора — %pM.

А где это можно использовать в ядре? Везде? Вот, например, в /arch/powerpc/boot/devtree.c можно? Или там еще какие-нибудь библиотеки не загружены?

[@andy_shev]

Вы задали хороший вопрос, возможно я напишу заметку о бардаке, который творится в arch/. Но если кратко, то arch/*/boot содержит для каждой архитектуры собственные библиотеки, т.к. на момент работы того кода основная часть ядра ещё не декомпрессирована.

[@mperepelitsyn]

В доках есть православный метод работы с linux-next — www.kernel.org/doc/man-pages/linux-next.html

[@mperepelitsyn]

Забыл написать сразу. Для тех, кто хочет познакомиться с ядром поближе, есть The Eudyptula Challenge, который на хабре почему-то освещен совсем слабо. 20 заданий, 2 из первых 18 (последние 2 не видел) — отправить тривиальный патч в staging — 1 найти с помощью checkpatch.pl, другой через sparse.

Так что checkpatch.pl и sparse можно использовать не только для проверки своих патчей, но и для нахождения фатальных недостатков в drivers/staging.

[@eldarmusin]

Блин, вот смотрю на всех вас. Энтузиасты, полны энергии, амбиций и времени. И завидно становится.
Молодцы, и спасибо за работу.

[@maksqwe]

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

[@eldarmusin]

Меня всего то на пару месяцев на OpenSuse хватило, а потом ребёнок родился и защита :(
С тех пор уже кроме мелких поделок для себя — ничего не делал.

[@maksqwe]

Да, иногда два 23' монитора не хватает дома, но привык работать и с ноутбучным 15ым.

[@lybin]

И из этой статьи можно поискать плохие куски кода: PVS-Studio покопался во внутренностях Linux

[@blueboar2]

Ну вот я нашел одно такое место, написал тем кто создавал/правил файл, у них почта давно протухла. Написал в мэйл-лист, там молчат. И чего делать?

[@RPG]

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

[@eldarmusin]

Мейнтейнер в тюрме! Аж заинтриговало его детище.

[@vlivyur]

Ханс Райзер

[@RPG]

ReiserFS, я промахнулся с добавлением комментария, там была ссылочка, которая при редактировании пропала.

P.S. Опередили:)

[@kmu1990]

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

[@andy_shev]

Добро пожаловать в клуб любителей SCSI! Вот www.spinics.net/lists/linux-rdma/msg19739.html ничего не напоминает? Посмотрите на дату :) Да, а по какаим адресам?

[@blueboar2]

Открыл дерево коммитов, поискал адреса в файле MAINTAINERS. Но как я понял, идея бесперспективная? Раз и вам год не ответили.

[@andy_shev]

Первая версия была в августе 2011 :-). Подсистема SCSI — самая консервативная в ядре. Туда удаётся пробить патчи, правда. Но это сопряжено с бешеными трудностями, так что это hard path. Вы посмотрите лучше на мой патч как образец и изменения (всё уходит в одну строку), и его оформления (поле темы, тело письма), а затем найдите что-нибудь в drivers/staging. Не зря же я про staging писал. Грег очень лояльный мейнтейнер, только обязательно проверяйте изменения перед оправкой как минимум компилированием и checkpatch.pl, иначе рассердите его!

[@RPG]

мимо