Re: ng_ipacct
- From
- Eugene Grosbein (2:5006/1)
- To
- dmitry@atlantis.dp.ua
- Date
- 2006-12-22T02:26:18Z
- Area
- RU.UNIX.BSD
Reply-To: eugen@grosbein.pp.ru
21 дек 2006, четверг, в 20:37 KRAST, dmitry@atlantis.dp.ua написал(а):
>> Отрицательный эффект дает вовсе не MODULES_WITH_WORLD, а игнорирование
>> требования держать ядро, мир и модули синхронизированными.
>> MODULES_WITH_WORLD этому требованию - не противоречит.
dadu> Эта переменная, однако, переносят "границу" (перестраивать / не
dadu> перестраивать) со стыка 1: (kernel+modules) <-> userland на стык
dadu> 2: kernel <-> (modules|userland), где '-' - граница. В
dadu> девелопмент-ветвях
dadu> (CURRENT, STABLE) коммиты практически всегда пересекают границу 2,
dadu> и весьма редко - границу 1. Да и последствия от разрыва на границе 2
dadu> (между kernel и modules) гораздо коварнее, чем на границе 1. Да что там
dadu> говорить, модуля _и_ kernel строятся из текстов иерархии src/sys,
dadu> userland
dadu> из-за ее пределов. Потому по-умолчанию граница проведена именно по стыку
dadu> 1 (между (kernel+modules) и userland), и это правильно.
Кого волнуют детали творческого процесса девелоперов,
когда дело касается рабочих систем, пусть это даже будет STABLE
как девелоперская ветка? При обновлении исходников надо пересобирать
и мир тоже, пересобирутся модули с ним или с ядром уже не важно.
Изменения конфигурации ядра без изменений исходников не требуют
оверхеда make modules и совершенно непонятно, зачем он нужен.
При изменении исходников все равно пересобирать всю систему,
и mergemaster тоже, да.
>>> Ну это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
>>> мира... Рекомендуемая процедура должна быть, в первую очередь,
>>> надежной, а во вторую эффективной и простой. Требование читать diff-ы
>>> не удовлетворяет второму :-) Требование при обновлении сорцов
dadu>> Откуда Вы откопали это требование? Я такого и между строк не писал.
>> Ну а как еще можно сделать вывод, что допустимо пересобрать ядро
>> с модулями без мира? Понадеяться на авось?
dadu> Ну почему сразу на авось? Я слежу и, смею утверждать, понимаю, что
dadu> меняется
dadu> в дереве, а что нет.
Но ведь нельзя от каждого админа требовать такого понимания.
Поэтому - следовать процедуре в UPDATING. Ну за исключением single useer
при смене ядра :-) Это технически далеко не всегда осуществимо,
сильно увеличивает downtime и вообще крайне редко надо (CURRENT не в счет).
dadu> А с технической точки зрения - см. выше.
Кроме diff-ов с технической точки зрения что-то ничего не видно;
вычитывание листа cvs-src не может быть техническим методом обеспечения
синхронности :-)
dadu> Ядро и модуля
dadu> из базовой системы, будучи загружены, работают по одну сторону высокой и
dadu> мощной стены, разделяющей kernel land и user land. Остальной мир - по
dadu> другую.
dadu> Эта стена узаконена аппаратно (на i386 - supervisor vs user mode), и на
dadu> "КПП" через нее (сисколлах) сравнительно редко что-то меняется.
Да не так уж редко. Если следовать принципу "работает - не трогай"
и обновлять систему в среднем раз в релиз (плюс когда Security Advisory
рекомендует), то пересобирать таки придется. А сильно чаще обновляться
смысла просто нет для стабильно работающих релизов/снапшотов.
dadu>> Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПНЫМ ШРИФТОМ) гораздо чаще
dadu>> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
dadu>> (disclamer: речь идет о домашних и тестовых машинах, НЕ о production).
>> И при этом мир не пересобираешь? Вот не надо бы такого озвучивать
>> без варнингов.
dadu> Каким шрифтом мне написать IMHO, чтобы Вы увидели?
IMHO это ни разу ни варнинг.
dadu>> Увы, при переходе от user-threads на 4ке на kernel threads 5+ без
dadu>> этого
dadu>> врядли можно было обойтись. Да и другие изменения от ветки к ветке
dadu>> достаточно
dadu>> глубоки. Вот в 7ке введут symbol versioning - посмотрим, полегчает ли в
dadu>> этом
dadu>> плане.
>> При переходе с 4 на 6 легко без этого обошелся на десктопе.
>> User-threads никуда не делись, и libc_r.so от четверки тоже.
dadu> А никто и не говорит, что работать не будет (для того и compatYx
dadu> создают,
dadu> чтобы работало).
Требование пересобирать трудно обосновать чем-то кроме неработы.
dadu> Насколько эффективно (например, разъедутся ли разные треды
dadu> по разным CPU) - вот в чем вопрос. Перекомпиляция нужна именно для
dadu> эффективной
dadu> работы, а не просто "работает/не работает".
"при переходе от user-threads на 4ке на kernel threads 5+ без
этого врядли можно было обойтись" я воспринимаю как утверждение
о "не-обходимости" пересборки, против чего и возражение. Легко можно
обойтись.
Eugene
--
Устав от радостных пиров,
Не зная страхов и желаний
--- slrn/0.9.8.0 (FreeBSD)
* Origin: Svyaz Service JSC (2:5006/1@fidonet)
SEEN-BY: 50/12 400/814 450/1024 5000/5000 5006/1 8 9 10 14 15 16 17 5011/13
SEEN-BY: 5012/46 5015/28 5019/26 5020/400 545 2238 2395 2871 4441 5021/29
SEEN-BY: 5025/3 5027/12 5030/1080 1957 5035/38 5045/7 5054/1 4 8 9 11 28 35 36
SEEN-BY: 5054/37 45 66 67 70 75 84 85 5059/9 5062/10 5063/3 5064/7 5076/1
SEEN-BY: 5077/70 5084/9 5085/13 5095/20 5096/18 6001/10
PATH: 5006/1 5020/400 545 5054/1 37