Re: ng_ipacct

From

Dmitry Pryanishnikov (2:464/36)

To

All

Date

2006-12-21T20:37:52Z

Area

RU.UNIX.BSD

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

On Thu, 21 Dec 2006, Eugene Grosbein wrote:
> Отрицательный эффект дает вовсе не MODULES_WITH_WORLD, а игнорирование
> требования держать ядро, мир и модули синхронизированными.
> MODULES_WITH_WORLD этому требованию - не противоречит.

   Эта переменная, однако, переносят "границу" (перестраивать / не 
перестраивать) со стыка 1: (kernel+modules) <-> userland на стык
2: kernel <-> (modules|userland), где '-' - граница. В девелопмент-ветвях 
(CURRENT, STABLE) коммиты практически всегда пересекают границу 2,
и весьма редко - границу 1. Да и последствия от разрыва на границе 2
(между kernel и modules) гораздо коварнее, чем на границе 1. Да что там
говорить, модуля _и_ kernel строятся из текстов иерархии src/sys, userland
из-за ее пределов. Потому по-умолчанию граница проведена именно по стыку
1 (между (kernel+modules) и userland), и это правильно.

> когда в июле 2004 послал подробный PR, который не получил ни одного followup
> и через полтора года был закрыт так и не пофикшенным в четверке.
> Из чего я сделал вывод, что у девелоперов есть дела поважнее,
> чем разбирать проблемы с kldunload, и это можно понять - выгружать
> модули при нормальной работе обычно не требуется. Поэтому такие PR
> не посылаю. А вот про функциональность, дело другое.

   Девелоперов много, и у всех разные приоритеты. Народ за 2 года сильно 
изменился, много свежих толковых людей пришло. Тот же Pyun YongHyeon - весьма 
толковый и активный коммитер (13-Dec втолкнул в CURRENT msk(4) для 
Marvell/SysKonnect Yukon II, я тестировал его на ASUS P5W DH - вроде ОК). 
Так что создавать стереотип "на это они забъют", IMHO, неправильно. Кто-то
забъет, а кто-то и нет.

> >> Ну это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
> >> мира... Рекомендуемая процедура должна быть, в первую очередь,
> >> надежной, а во вторую эффективной и простой. Требование читать diff-ы
> >> не удовлетворяет второму :-) Требование при обновлении сорцов
> dadu>    Откуда Вы откопали это требование? Я такого и между строк не писал.
>
> Ну а как еще можно сделать вывод, что допустимо пересобрать ядро
> с модулями без мира? Понадеяться на авось?

   Ну почему сразу на авось? Я слежу и, смею утверждать, понимаю, что меняется
в дереве, а что нет. А с технической точки зрения - см. выше. Ядро и модуля
из базовой системы, будучи загружены, работают по одну сторону высокой и
мощной стены, разделяющей kernel land и user land. Остальной мир - по другую.
Эта стена узаконена аппаратно (на i386 - supervisor vs user mode), и на
"КПП" через нее (сисколлах) сравнительно редко что-то меняется.

> dadu>    Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПНЫМ ШРИФТОМ) гораздо чаще
> dadu> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
> dadu> (disclamer: речь идет о домашних и тестовых машинах, НЕ о production).
>
> И при этом мир не пересобираешь? Вот не надо бы такого озвучивать
> без варнингов.

   Каким шрифтом мне написать IMHO, чтобы Вы увидели? На HTML переходить?
Не дождетесь!

> dadu>    Увы, при переходе от user-threads на 4ке на kernel threads 5+ без
> dadu>    этого
> dadu> врядли можно было обойтись. Да и другие изменения от ветки к ветке
> dadu> достаточно
> dadu> глубоки. Вот в 7ке введут symbol versioning - посмотрим, полегчает ли в
> dadu> этом
> dadu> плане.
>
> При переходе с 4 на 6 легко без этого обошелся на десктопе.
> User-threads никуда не делись, и libc_r.so от четверки тоже.

   А никто и не говорит, что работать не будет (для того и compatYx создают,
чтобы работало). Насколько эффективно (например, разъедутся ли разные треды
по разным CPU) - вот в чем вопрос. Перекомпиляция нужна именно для эффективной
работы, а не просто "работает/не работает".

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

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