|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Eugene Grosbein 2:5006/1 21 Dec 2006 22:46:13
To : dmitry@atlantis.dp.ua
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
21 дек 2006, четверг, в 15:19 KRAST, dmitry@atlantis.dp.ua написал(а):
>>> Все такие странные проблемы уходят, всем рекомендую.
dadu>> IMHO зря _всем_ рекомендуете. Для тех, кто часто обновляет исходники
dadu>> _и_
dadu>> перестраивает ядро это плохой, негодный совет. Я, например, при
dadu>> очередном
dadu>> обновлении STABLE смотрю лог csup (а часто и diff -u старого и нового
dadu>> src),
dadu>> и, если изменения принципиальные только в ядре (а остальной мир
dadu>> практически
dadu>> не изменился) - делаю только make kernel.
>> Было ведь жесткое правило - держать ядро и мир
>> синхронизированными,
>> ну вот нафига пропагандировать его отмену? Сорцы обновил - пересобирай.
dadu> Hу и кто из нас пропагандирует? Я пишу: "IMHO зря _всем_
dadu> рекомендуете...
dadu> Я, например" - я привожу конкретный случай, когда Ваш совет дает
dadu> отрицательный
dadu> эффект, а вовсе не призываю всех, включая шушпанчиков с покемонами,
dadu> следовать
dadu> за мной. А вот "всем рекомендую" - это Ваши слова.
Отрицательный эффект дает вовсе не MODULES_WITH_WORLD, а игнорирование
требования держать ядро, мир и модули синхронизированными.
MODULES_WITH_WORLD этому требованию - не противоречит.
>> Если же только эксперименты с конфигом ядра, модули пересобирать
>> почти всегда не надо.
dadu> А если ошибка именно в модуле? Как Вы тут попросили 6 октября
dadu> выгрузить
dadu> fdc.ko? Hе написали, кстати, офигенными буквами, что крах будет?! А в
dadu> час
dadu> ночи чужие мысли читать не всегда удается. Выгрузил, блин ;(
Я же попросил делать это в single user, выполнив полную перезагрузку.
То есть, без смонтированных fs и с рутом в r/o. Крах в этом варианте
не страшен.
dadu> А где же Ваш PR на эту тему? Мой 104079.
Мой патч на тему fdc.ko это kern/103841, только он не про unload module,
а про собственно функциональность fdc. Про панику после kldunload
у меня был отрицательный опыт с PR kern/69058 в 4.10-STABLE,
когда в июле 2004 послал подробный PR, который не получил ни одного followup
и через полтора года был закрыт так и не пофикшенным в четверке.
Из чего я сделал вывод, что у девелоперов есть дела поважнее,
чем разбирать проблемы с kldunload, и это можно понять - выгружать
модули при нормальной работе обычно не требуется. Поэтому такие PR
не посылаю. А вот про функциональность, дело другое.
dadu>> Hо устаревшие модуля мне,
dadu>> естественно, не нужны. Ведь и ядро, и модуля, которые строит
dadu>> buildkernel
dadu>> -
dadu>> продукт одних и тех же текстов из src/sys, они тесно интегрированы,
dadu>> разрывать их перестроение - чревато тонкими глюками и невозможностью
dadu>> толком
dadu>> проанализировать kernel dump.
>> А еще бывают те же связки ядра и userland, поэтому модули пересобираются
>> вместе с миром, а мир - с изменением исходников. Или типа стабильность ABI
>> уже это требование похоронила?
dadu> Hу Вы же сами прекрасно понимаете, что "родные" фришные модуля не
dadu> обязаны
dadu> ограничиваться тем подмножеством ABI, которое официально документируется
dadu> проектом для третьих разработчиков?
Я имею в виду ABI между kernel land и user land.
dadu>> Вот как раз порты, кладя в /boot/modules свои модуля, порождают кучу
dadu>> вопросов у пользователей-не-девелоперов, когда последние обновляют
dadu>> систему,
dadu>> а она, погань, слетает при перезагрузке из-за устаревшего драйвера
dadu>> nVidia
dadu>> или какого-нибудь rtc.ko. Тут MODULES_WITH_WORLD AFAIK ничем помочь не
dadu>> может (а созданием в /boot/modules мешанины из актуальных базовых и
dadu>> устаревших портовых модулей, наоборот, навредит).
>>
>> Hу это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
>> мира... Рекомендуемая процедура должна быть, в первую очередь,
>> надежной, а во вторую эффективной и простой. Требование читать diff-ы
>> не удовлетворяет второму :-) Требование при обновлении сорцов
dadu> Откуда Вы откопали это требование? Я такого и между строк не писал.
Hу а как еще можно сделать вывод, что допустимо пересобрать ядро
с модулями без мира? Понадеяться на авось?
>> пересобирать ядро, модули и мир и портовые модули удовлетворяется
>> хоть при использовании MODULES_WITH_WORLD, хоть без. Hо при использовании
>> пересборка ядра без изменения сорцов, во-первых, не дает проблем
>> с портовыми модулями (а без - проблемы есть), а во-вторых, гораздо
>> эффективнее в смысле глупого оверхеда на пересборку модулей.
dadu> Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПHЫМ ШРИФТОМ) гораздо чаще
dadu> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
dadu> (disclamer: речь идет о домашних и тестовых машинах, HЕ о production).
И при этом мир не пересобираешь? Вот не надо бы такого озвучивать
без варнингов.
>> Мне вообще активно не нравится требование обновлять /usr/local
>> при смене версии OS. И я не обновлял ничего при переходе с четверки
>> на шестерку дома, за исключением досадных вещей типа смены
>> locale on-disk format, работало все, начиная от XFree86 и кончая
>> galeon-ом через compat4x без проблем.
dadu> Увы, при переходе от user-threads на 4ке на kernel threads 5+ без
dadu> этого
dadu> врядли можно было обойтись. Да и другие изменения от ветки к ветке
dadu> достаточно
dadu> глубоки. Вот в 7ке введут symbol versioning - посмотрим, полегчает ли в
dadu> этом
dadu> плане.
При переходе с 4 на 6 легко без этого обошелся на десктопе.
User-threads никуда не делись, и libc_r.so от четверки тоже.
Eugene
--
Choose no career
--- slrn/0.9.8.0 (FreeBSD)
* Origin: Svyaz Service JSC (2:5006/1@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
