|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Pryanishnikov 2:464/36 21 Dec 2006 16:19:27
To : Eugene Grosbein
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
Привет!
On Thu, 21 Dec 2006, Eugene Grosbein wrote:
>> Все такие странные проблемы уходят, всем рекомендую.
> dadu> IMHO зря _всем_ рекомендуете. Для тех, кто часто обновляет исходники
> dadu> _и_
> dadu> перестраивает ядро это плохой, негодный совет. Я, например, при
> dadu> очередном
> dadu> обновлении STABLE смотрю лог csup (а часто и diff -u старого и нового
> dadu> src),
> dadu> и, если изменения принципиальные только в ядре (а остальной мир
> dadu> практически
> dadu> не изменился) - делаю только make kernel.
>
> Было ведь жесткое правило - держать ядро и мир
синхронизированными,
> ну вот нафига пропагандировать его отмену? Сорцы обновил - пересобирай.
у и кто из нас пропагандирует? Я пишу: "IMHO зря _всем_ рекомендуете...
Я, например" - я привожу конкретный случай, когда Ваш совет дает отрицательный
эффект, а вовсе не призываю всех, включая шушпанчиков с покемонами, следовать
за мной. А вот "всем рекомендую" - это Ваши слова.
> Если же только эксперименты с конфигом ядра, модули пересобирать
> почти всегда не надо.
А если ошибка именно в модуле? Как Вы тут попросили 6 октября выгрузить
fdc.ko? е написали, кстати, офигенными буквами, что крах будет?! А в час
ночи чужие мысли читать не всегда удается. Выгрузил, блин ;(
А где же Ваш PR на эту тему? Мой 104079. Кстати, мне Pyun YongHyeon выслал
патч от этой проблемы, жду, пока починят анализ бэктрейсов в CURRENT
(поломали 17 декабря около 5:00 GMT), чтобы оттестить. Так вот, патч латает
именно модуль, а не ядро. И хоть Dennis Chikin тут утверждал, что именно
devfs мешает нам строить и жить, но патч правит взаимодействие не с devfs, а
с GEOM.
> dadu> Hо устаревшие модуля мне,
> dadu> естественно, не нужны. Ведь и ядро, и модуля, которые строит buildkernel
> dadu> -
> dadu> продукт одних и тех же текстов из src/sys, они тесно интегрированы,
> dadu> разрывать их перестроение - чревато тонкими глюками и невозможностью
> dadu> толком
> dadu> проанализировать kernel dump.
>
> А еще бывают те же связки ядра и userland, поэтому модули пересобираются
> вместе с миром, а мир - с изменением исходников. Или типа стабильность ABI
> уже это требование похоронила?
у Вы же сами прекрасно понимаете, что "родные" фришные модуля не обязаны
ограничиваться тем подмножеством ABI, которое официально документируется
проектом для третьих разработчиков?
> dadu> Вот как раз порты, кладя в /boot/modules свои модуля, порождают кучу
> dadu> вопросов у пользователей-не-девелоперов, когда последние обновляют
> dadu> систему,
> dadu> а она, погань, слетает при перезагрузке из-за устаревшего драйвера
> dadu> nVidia
> dadu> или какого-нибудь rtc.ko. Тут MODULES_WITH_WORLD AFAIK ничем помочь не
> dadu> может (а созданием в /boot/modules мешанины из актуальных базовых и
> dadu> устаревших портовых модулей, наоборот, навредит).
>
> Hу это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
> мира... Рекомендуемая процедура должна быть, в первую очередь,
> надежной, а во вторую эффективной и простой. Требование читать diff-ы
> не удовлетворяет второму :-) Требование при обновлении сорцов
Откуда Вы откопали это требование? Я такого и между строк не писал.
> пересобирать ядро, модули и мир и портовые модули удовлетворяется
> хоть при использовании MODULES_WITH_WORLD, хоть без. Hо при использовании
> пересборка ядра без изменения сорцов, во-первых, не дает проблем
> с портовыми модулями (а без - проблемы есть), а во-вторых, гораздо
> эффективнее в смысле глупого оверхеда на пересборку модулей.
Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПЫМ ШРИФТОМ) гораздо чаще
обновляю исходники базовой ОС и пересобираю именно ее, чем порты
(disclamer: речь идет о домашних и тестовых машинах, Е о production).
> dadu> IMHO /boot/modules примерно
> dadu> так же соотносится с /boot/kernel, как /usr/local с /usr: при обновлении
> dadu>
> dadu> текстов ядра (мира) мы пересобираем содержимое /boot/kernel
> dadu> (/usr/не-local), а
> dadu> своевременное обновление /boot/modules и /usr/local при смене веток,
> dadu> например,
> dadu> RELENG_5 -> 6 - за этим уже мы сами (или наши скрипты, но не базовый
> dadu> {build,install}{kernel,world}) должны следить.
>
> Мне вообще активно не нравится требование обновлять /usr/local
> при смене версии OS. И я не обновлял ничего при переходе с четверки
> на шестерку дома, за исключением досадных вещей типа смены
> locale on-disk format, работало все, начиная от XFree86 и кончая
> galeon-ом через compat4x без проблем.
Увы, при переходе от user-threads на 4ке на kernel threads 5+ без этого
врядли можно было обойтись. Да и другие изменения от ветки к ветке достаточно
глубоки. Вот в 7ке введут symbol versioning - посмотрим, полегчает ли в этом
плане.
> Eugene
Sincerely, Dmitry
--
Atlantis ISP, System Administrator
e-mail: dmitry@atlantis.dp.ua
nic-hdl: LYNX-RIPE
--- ifmail v.2.14.os-p7
* Origin: Atlantis ISP (2:464/36@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
