|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Dmitry Pryanishnikov 2:464/36 21 Dec 2006 21:37:53
To : All
Subject : Re: ng_ipacct
--------------------------------------------------------------------------------
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, неправильно. Кто-то
забъет, а кто-то и нет.
> >> Hу это вопрос аккуратности, можно и UPDATING не читать перед пересборкой
> >> мира... Рекомендуемая процедура должна быть, в первую очередь,
> >> надежной, а во вторую эффективной и простой. Требование читать diff-ы
> >> не удовлетворяет второму :-) Требование при обновлении сорцов
> dadu> Откуда Вы откопали это требование? Я такого и между строк не писал.
>
> Hу а как еще можно сделать вывод, что допустимо пересобрать ядро
> с модулями без мира? Понадеяться на авось?
у почему сразу на авось? Я слежу и, смею утверждать, понимаю, что меняется
в дереве, а что нет. А с технической точки зрения - см. выше. Ядро и модуля
из базовой системы, будучи загружены, работают по одну сторону высокой и
мощной стены, разделяющей kernel land и user land. Остальной мир - по другую.
Эта стена узаконена аппаратно (на i386 - supervisor vs user mode), и на
"КПП" через нее (сисколлах) сравнительно редко что-то меняется.
> dadu> Ту хум хау. Я как раз (я, IMHO САМЫМ КРУПHЫМ ШРИФТОМ) гораздо чаще
> dadu> обновляю исходники базовой ОС и пересобираю именно ее, чем порты
> dadu> (disclamer: речь идет о домашних и тестовых машинах, HЕ о 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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
