Re: ng_ipacct

From

Eugene Grosbein (2:5006/1)

To

dmitry@atlantis.dp.ua

Date

2006-12-21T21:46:12Z

Area

RU.UNIX.BSD

Reply-To: eugen@grosbein.pp.ru

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>    Ну и кто из нас пропагандирует? Я пишу: "IMHO зря _всем_
 dadu>    рекомендуете...
 dadu> Я, например" - я привожу конкретный случай, когда Ваш совет дает
 dadu> отрицательный
 dadu> эффект, а вовсе не призываю всех, включая шушпанчиков с покемонами,
 dadu> следовать 
 dadu> за мной. А вот "всем рекомендую" - это Ваши слова.

Отрицательный эффект дает вовсе не MODULES_WITH_WORLD, а игнорирование
требования держать ядро, мир и модули синхронизированными.
MODULES_WITH_WORLD этому требованию - не противоречит.

 >> Если же только эксперименты с конфигом ядра, модули пересобирать
 >> почти всегда не надо.
 dadu>    А если ошибка именно в модуле? Как Вы тут попросили 6 октября
 dadu>    выгрузить 
 dadu> fdc.ko? Не написали, кстати, офигенными буквами, что крах будет?! А в
 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>> Но устаревшие модуля мне,
 dadu>> естественно, не нужны. Ведь и ядро, и модуля, которые строит
 dadu>> buildkernel
 dadu>> -
 dadu>> продукт одних и тех же текстов из src/sys, они тесно интегрированы,
 dadu>> разрывать их перестроение - чревато тонкими глюками и невозможностью
 dadu>> толком
 dadu>> проанализировать kernel dump.

 >> А еще бывают те же связки ядра и userland, поэтому модули пересобираются
 >> вместе с миром, а мир - с изменением исходников. Или типа стабильность ABI
 >> уже это требование похоронила?
 dadu>    Ну Вы же сами прекрасно понимаете, что "родные" фришные модуля не
 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>> устаревших портовых модулей, наоборот, навредит).
 >>
 >> Ну это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
 >> мира... Рекомендуемая процедура должна быть, в первую очередь,
 >> надежной, а во вторую эффективной и простой. Требование читать diff-ы
 >> не удовлетворяет второму :-) Требование при обновлении сорцов
 dadu>    Откуда Вы откопали это требование? Я такого и между строк не писал.

Ну а как еще можно сделать вывод, что допустимо пересобрать ядро
с модулями без мира? Понадеяться на авось?

 >> пересобирать ядро, модули и мир и портовые модули удовлетворяется
 >> хоть при использовании MODULES_WITH_WORLD, хоть без. Но при использовании
 >> пересборка ядра без изменения сорцов, во-первых, не дает проблем
 >> с портовыми модулями (а без - проблемы есть), а во-вторых, гораздо
 >> эффективнее в смысле глупого оверхеда на пересборку модулей.
 dadu>    Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПНЫМ ШРИФТОМ) гораздо чаще
 dadu> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
 dadu> (disclamer: речь идет о домашних и тестовых машинах, НЕ о 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)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 8 9 10 14 15 16 17 5007/1 5010/70
SEEN-BY: 5011/13 5012/46 5015/28 5019/26 5020/18 175 194 400 545 982 1057 1909
SEEN-BY: 5020/1922 2238 2395 2871 4441 5021/29 5025/3 5026/14 45 5027/12
SEEN-BY: 5030/1080 1957 5034/10 13 5035/38 5036/1 5045/7 5049/1 5051/15 5054/1
SEEN-BY: 5054/4 8 9 11 28 35 36 37 45 66 67 70 75 84 85 5059/9 5060/88 5061/15
SEEN-BY: 5062/10 5063/3 5064/7 5066/18 5075/5 5076/1 5077/70 5084/9 5085/13
SEEN-BY: 5095/20 5096/18 6001/10

PATH: 5006/1 5020/400 545 5054/1 37