Comments 29
Насколько мощная машина нужна для сборки ядра в приемлемое время?
На стационарнике i5-3470 в 5 потоков собирается минут за 10. Но у меня все необходимое включено в ядро, без модулей :)
Если модули лишние поотключать — любой не нетбук до 5 лет выдержки.
У меня на A10-5850 в 6 потоков —
real 3m25.969s
user 11m33.297s
sys 0m45.940s
Но я думаю в 2.5 реально уложиться — еще много всего не выкинул лишнего из модулей, да и диск очень старый.
У меня на A10-5850 в 6 потоков —
real 3m25.969s
user 11m33.297s
sys 0m45.940s
Но я думаю в 2.5 реально уложиться — еще много всего не выкинул лишнего из модулей, да и диск очень старый.
За удобную отправку в нужные ML и мейнтернерам огромное спасибо! В свое время намучился вручную через консольные мейл-клиенты отправлять, так как некоторые GUI клиенты портили патчи.
/* make debug message */
msg[0] = '\0';
for (j = 0; j < i; j++) {
snprintf(str, 128, " %02X", buf[j]);
strcat(msg, str);
}
Алгоритм маляра Шлемиэля даже в ядре? Хотя это скорее всего никому не нужный драйвер. Одно дело если бы такая ошибка была в fs/ и другое — в каком-то драйвере, которым пользуются только экстремалы.
--git-min-percent=67
Это хорошо, да. А то, бывает, поправишь где-нибудь три строчки, а любители get_maintainer.pl начинают тебя после этого в cc: включать.
В списке рассылки qemu-devel однажды поднималась эта тема, с пожеланиями включить --no-git-fallback по умолчанию.
Не забываем патч прогнать через checkpatch.pl
А это оказывается кто-то так выводит MAC адрес! Что ж, мы с лёгкостью можем использовать специальное расширение спецификатора — %pM.
А где это можно использовать в ядре? Везде? Вот, например, в /arch/powerpc/boot/devtree.c можно? Или там еще какие-нибудь библиотеки не загружены?
В доках есть православный метод работы с linux-next — www.kernel.org/doc/man-pages/linux-next.html
Забыл написать сразу. Для тех, кто хочет познакомиться с ядром поближе, есть The Eudyptula Challenge, который на хабре почему-то освещен совсем слабо. 20 заданий, 2 из первых 18 (последние 2 не видел) — отправить тривиальный патч в staging — 1 найти с помощью checkpatch.pl, другой через sparse.
Так что checkpatch.pl и sparse можно использовать не только для проверки своих патчей, но и для нахождения фатальных недостатков в drivers/staging.
Так что checkpatch.pl и sparse можно использовать не только для проверки своих патчей, но и для нахождения фатальных недостатков в drivers/staging.
Блин, вот смотрю на всех вас. Энтузиасты, полны энергии, амбиций и времени. И завидно становится.
Молодцы, и спасибо за работу.
Молодцы, и спасибо за работу.
Вот со временем, не совсем так. Бывает из-за этого энтузиазма все выходные дома за ноутом просидишь. Но бывает это меня спасало от походов по магазинам с женой — «Я очень занят, разбираюсь с очень плохой багой у нас, времени нет, иди с подружками сама», а сам в Qt колупаюсь, патчик готовлю под пиво :)
И из этой статьи можно поискать плохие куски кода: PVS-Studio покопался во внутренностях Linux
Ну вот я нашел одно такое место, написал тем кто создавал/правил файл, у них почта давно протухла. Написал в мэйл-лист, там молчат. И чего делать?
Ответ не обязательно придет сразу, это же опенсорс. Мейнтейнер вашего куска кода может быть в отпуске или в тюрьме. А если исправление касалось очень старого драйвера — возможно сам драйвер попахивает и пора поднимать вопрос о его исключении? Для оперативного обсуждения можно попробовать в IRC (тоже не факт что ответят сразу).
Мейнтейнер в тюрме! Аж заинтриговало его детище.
ReiserFS, я промахнулся с добавлением комментария, там была ссылочка, которая при редактировании пропала.
P.S. Опередили:)
P.S. Опередили:)
Во-первых, может потребоваться какое-то время на ответ, конкретное время зависит от подсистемы, в которую вы отправили патч. Различные исправления кодстайла, мелкие чистки кода и другие некритические изменения, часто, имеют меньший приоритет, по сравнению с исправлениями багов, так что нет ничего удивительного, что вам не отвечают сразу.
Во-вторых, перед тем как отправить патч стоило почитать правила, которым он должен удовлетворять, как минимум должен быть Signed-off-by и описание изменений. Правила описаны тут.
Во-вторых, перед тем как отправить патч стоило почитать правила, которым он должен удовлетворять, как минимум должен быть Signed-off-by и описание изменений. Правила описаны тут.
Добро пожаловать в клуб любителей SCSI! Вот www.spinics.net/lists/linux-rdma/msg19739.html ничего не напоминает? Посмотрите на дату :) Да, а по какаим адресам?
Открыл дерево коммитов, поискал адреса в файле MAINTAINERS. Но как я понял, идея бесперспективная? Раз и вам год не ответили.
Первая версия была в августе 2011 :-). Подсистема SCSI — самая консервативная в ядре. Туда удаётся пробить патчи, правда. Но это сопряжено с бешеными трудностями, так что это hard path. Вы посмотрите лучше на мой патч как образец и изменения (всё уходит в одну строку), и его оформления (поле темы, тело письма), а затем найдите что-нибудь в drivers/staging. Не зря же я про staging писал. Грег очень лояльный мейнтейнер, только обязательно проверяйте изменения перед оправкой как минимум компилированием и checkpatch.pl, иначе рассердите его!
мимо
Sign up to leave a comment.
Сделаем код чище: Что можно исправить в ядре Linux