Re: ng_ipacct

From

Dmitry Pryanishnikov (2:464/36)

To

Eugene Grosbein

Date

2006-12-21T15:19:26Z

Area

RU.UNIX.BSD

From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>


Привет!

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> Но устаревшие модуля мне,
> 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> устаревших портовых модулей, наоборот, навредит).
>
> Ну это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
> мира... Рекомендуемая процедура должна быть, в первую очередь,
> надежной, а во вторую эффективной и простой. Требование читать diff-ы
> не удовлетворяет второму :-) Требование при обновлении сорцов

   Откуда Вы откопали это требование? Я такого и между строк не писал.

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

   Ту хум хау. Я как раз (я, 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)
SEEN-BY: 46/999 50/12 400/814 450/1024 463/68 464/0 36 66 100 128 999 465/213
SEEN-BY: 550/5068 5000/0 20 26 27 61 94 104 116 130 170 5000 5002/76 5002
SEEN-BY: 5004/75 1111 5005/14 5009/14 5010/77 275 5011/13 5012/46 5013/21
SEEN-BY: 5015/28 5019/26 5020/400 545 2238 2395 2871 4441 5021/29 5025/3
SEEN-BY: 5027/12 5029/34 5030/1080 1957 5035/38 5045/7 5054/1 4 8 9 11 28 35
SEEN-BY: 5054/36 37 45 66 67 70 75 84 85 5055/177 5057/119 5059/9 5062/10
SEEN-BY: 5063/3 5064/7 5070/66 5076/1 5077/70 5084/9 5085/13 5090/1029 5095/20
SEEN-BY: 5096/18 6001/10 6090/1

PATH: 464/36 5000/5000 5020/545 5054/1 37