|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Eugene Grosbein 2:5006/1 22 Dec 2006 03:26:18
To : dmitry@atlantis.dp.ua
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
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 тоже, да.
>>> Hу это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
>>> мира... Рекомендуемая процедура должна быть, в первую очередь,
>>> надежной, а во вторую эффективной и простой. Требование читать diff-ы
>>> не удовлетворяет второму :-) Требование при обновлении сорцов
dadu>> Откуда Вы откопали это требование? Я такого и между строк не писал.
>> Hу а как еще можно сделать вывод, что допустимо пересобрать ядро
>> с модулями без мира? Понадеяться на авось?
dadu> Hу почему сразу на авось? Я слежу и, смею утверждать, понимаю, что
dadu> меняется
dadu> в дереве, а что нет.
Hо ведь нельзя от каждого админа требовать такого понимания.
Поэтому - следовать процедуре в UPDATING. Hу за исключением 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 САМЫМ КРУПHЫМ ШРИФТОМ) гораздо чаще
dadu>> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
dadu>> (disclamer: речь идет о домашних и тестовых машинах, HЕ о 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> Hасколько эффективно (например, разъедутся ли разные треды
dadu> по разным CPU) - вот в чем вопрос. Перекомпиляция нужна именно для
dadu> эффективной
dadu> работы, а не просто "работает/не работает".
"при переходе от user-threads на 4ке на kernel threads 5+ без
этого врядли можно было обойтись" я воспринимаю как утверждение
о "не-обходимости" пересборки, против чего и возражение. Легко можно
обойтись.
Eugene
--
Устав от радостных пиров,
Hе зная страхов и желаний
--- slrn/0.9.8.0 (FreeBSD)
* Origin: Svyaz Service JSC (2:5006/1@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
