[d-kernel] q: modutils vs module-init-tools

[d-kernel] q: modutils vs module-init-tools

[Michael Shigorin]

[-- Attachment #1.1: Type: text/plain, Size: 8360 bytes --]

	Здравствуйте.
Сегодня на #altlinux имели место очередные прения.

Лог прилагаю; по возможности извлеку из него ключевые моменты.

Фактически обсуждалось:

- каким (и когда) modutils быть в Sisyphus
- важно ли, чтобы они были "как у всех".

Мнение группы ab, UlfR, lioka, Grigory и вашего покорного слуги
вкратце сводится к "надо, чтоб работало и поддерживалось; как у
других -- дело десятое".  Вывод -- взять modutils имени UlfR из
people/ed/.

Мнение rider (отчасти при поддержке vsu и со ссылками на ldv)
рискну просуммировать как "нам вдруг стало небезразлично, как там
что в Fedora и SuSE".  Вывод -- тащить modutils из Fedora.

Субъективно -- последнее выглядит интересным исключением из
типично наблюдаемых в течение ряда последних лет тенденций
развития Sisyphus как оригинального репозитория с вагоном
know-how, из которого получаются удобные и выгодные в
долговременной эксплуатации продукты.

2 ldv: какие проблемы с modutils-2.4.25-alt16?

PS: субъективно -- "тащить федорино горе" есть безумие, потому
как это вовсе не редхат, и бултыхаются они сейчас в проблемах
нашей трехлетней давности, судя по fedora-package-announce@.
Смотреть на них в таком системообразующем вопросе -- глупо и
смешно.  А отказываться от проверенного варианта в пользу
концепт-кара с "простым" (нафигнужным) патчем -- безумие.

---

<UlfR> vsu: надобы свести воедино modutils. Я таки добавил *.inputmap

<vsu> UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils
<UlfR> vsu: тогда какие предложения? 
<vsu> UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools
<ab> vsu: Мы теряем главное -- макроязык

<ab> vsu: он (м-и-т) вообще покоцанный, это не показатель.
<ab> vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг"

<rider> ab: просто у меня возникает ощущение, что мы делаем что-то не то.. 
<vsu> ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :(

<rider> ab: очень не хотелось бы делать fork modutils ;-(
<ab> rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т

<vsu> ab: а написание "modutils 2.5.x" так и сдохло?
<ab> vsu: оно выродилось в то, что сделал Rusty
<rider> ab: так пинайте автора mit, тем более патчи уже есть
<ab> rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал
<ab> rider: и я с ним согласен.
<rider> ab: ты про то, что пускай все делают обертки сами ?
<ab> он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны

<ab> rider: в результате остается два пути: 
<ab>  - развивать направление, начатое Глебом
<ab>  - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils
<ab> Второй вариант, при грамотной реализации, может быть принят остальными вендорами.

<rider> ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ?
<ab> rider: нет, так не пойдет -- это глупо.
<ab> rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами.
<rider> ab: почему ? modutils из fedora вполне неплохой.
<ab> rider: еще раз -- у него унифицированный макроязык для всех ядер?
<rider> ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность
<ab> rider: я не вижу от него вопросов по патчам.

<rider> ab: а зачем нам нужна эта унификация ?
<rider> ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ?
<ab> rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож
<ab> но добиться унификации 
[skip]
<ab> rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д.
<ab> rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д.
<rider> ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот
<rider> ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная.
<rider> ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. 
<ab> rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. 
<ab> rider: потому что они не делают appliances :)
<ab> rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале.
<rider> ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях

<rider> ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры)
<ab> rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам.

<lioka> решают те, кто саппортит. 
<ab> rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. 
<gvy> именно, в итоге
<UlfR> ab: согласен
<Grigory> Тут я уже видел apt для RH. Ждем? :-)
<lioka> а 'майнстримового' саппорта не бывает. period

<ab> rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов.

<rider> gvy: ладно, зачем еще макроязык нужен ?
<gvy> rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка)
<gvy> в течение жизненного цикла 2.4
<rider> gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ?
<gvy> для _единообразной_ поддержки.
<gvy> rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине:
<rider> gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ?
<gvy> ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор;
<gvy> они будут или _знать_ про то, как это было с 2.4 (=> опытные),
<rider> gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться.
<gvy> или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...)
<gvy> так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет
<rider> gvy: я не понял про YaST
<gvy> сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4"
[skip]
<gvy> rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим
<gvy> а эти идиоты полромали -- ну так это проблемы _их_ клиентов

<ab> rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан.
<ab> rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт.
<gvy> rider, а где можно ознакомиться с претензиями ldv?  в devel-kernel@ было?
<rider> ab: верю, сам на нем сижу.. иди доказывай это ldv. 

<vsu> gvy: а багов в том патче есть... как, впрочем, и в чистом mit
<gvy> vsu, баги всегда есть
<ab> vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #1.2: altlinux-irc-modutils-20040209.log --]
[-- Type: text/plain, Size: 28884 bytes --]

--> vsu (~vsu@mivlgu.ru) has joined #altlinux
<vsu> $@#$%#$#%@#$%#$#$@ detectloader!!!
<UlfR> vsu: 
<vsu> UlfR: 
<UlfR> vsu: надобы свести воедино modutils. Я таки добавил *.inputmap
<vsu> UlfR: вообще есть мнение, что добавлять всё-таки надо не так
<UlfR> vsu: ?
<vsu> UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils
<UlfR> vsu: тогда какие предложения? 
<vsu> UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools
<vsu> UlfR: insmod в принципе тоже
<vsu> UlfR: т.е. фактически сильно патчить нужно только modprobe
<ab> vsu: зачем? 
<ab> vsu: Мы теряем главное -- макроязык
<vsu> ab: так макроязык как раз весь в modprobe
<ab> vsu: и в depmod
<vsu> ab: pcimapfile=...?  так он и для 2.4, похоже, уже сломан
<ab> vsu: не только. Там больше.
<vsu> ab: что именно?
<UlfR> vsu: всё что *file
<UlfR> vsu: generic_stringfile, depfile, ..., prune
<ab> vsu: он линкуется с config_read, соответственно, читает конфигурационный файл и парсит все
<vsu> UlfR: ну и кому оно нужно?  это уже сейчас сломано, и никто не заметил
<ab> vsu: заметили. Это отлично видно на новом hotplug
--> rider_ (~rider@altlinux.balabanovo.ru) has joined #altlinux
<vsu> ab: а что, новый hotplug хочет засовывать эти файлы куда-то в другое место?
<gvy> rider_, ! :)
<ab> vsu: суть не в "засовывать", а в "использовать". Новый хотплаг использует много.
<ab> vsu: в частности, умеет использовать input
<rider_> hi ppl
--- rider_ is now known as rider
<vsu> ab: т.е. ему нужен /lib/modules/`uname -r`/modules.input (или как там он точно называется)?
<ab> vsu: inputmap
<rider> ab: замечания по Max'у ?
<vsu> ab: ну и каким боком здесь макроязык?  depmod и без него этот файл сделает
<rider> ab: ааа.. да, есть такое дело.. сейчас перешлю
<ab> vsu: при том, что depmod не будет работать, если не сможет распарсить основной конфиг.
<ab> vsu: вообще не будет работать.
<vsu> ab: depmod из module-init-tools вообще в конфиг не смотрит
<ab> vsu: он (м-и-т) вообще покоцанный, это не показатель.
<ab> vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг"
<vsu> ab: вообще реально все эти path и *file из modules.conf кому-нибудь нужны?
<ab> vsu: да
<ab> vsu: в частности, для сосуществования межархитектурных карт (32/64)
<vsu> ab: и куда они в подобном случае показывают?
<rider> ab: ушел
<ab> vsu: обычно они показывают в значения по умолчанию, но при помощи MODPATH их можно переопределить
<rider> ab: а вы не писали автору module-init-tools и автору modutils письмо с патчем, объединяющим функциональность ?
<ab> rider: UlfR что-то писал
<rider> UlfR: а ответ пришел ?
<UlfR> rider: он в отпуске был
<rider> ab: просто у меня возникает ощущение, что мы делаем что-то не то.. 
<UlfR> на неделе отпишу ещё раз
<vsu> ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :(
<rider> UlfR: отпиши плз
<rider> vsu: именно ;-(
* mouse is back (gone 93:22:07)
<mouse> rider: vsu
<mouse> UlfR: 
<mouse> ab: hi
<vsu> mouse: 
<rider> mouse: привет ! ты куда пропал ?
<UlfR> mouse: 
<ab> vsu: объясни мне, _зачем_ идти следом за Расти в его упрощениях, если при этом теряется основной функционал, а он сам заявляет: "я специально делаю проще, чтобы другие могли сделать как надо для них"
<rider> ab: так может быть и сделать так как надо нам, но не патчами, а оберткой над module-init-tools ?
<vsu> ab: покажи, кому реально нужен этот функционал именно в depmod
<vsu> ab: по поводу modprobe я как раз не спорю
<vsu> ab: и то - *path там и для 2.4 уже сколько времени сломаны, и никто не замечает. значит, не нужны
<rider> UlfR: ed'а нет сегодня ?
<UlfR> rider: нет он в отпуске на недельку
<rider> UlfR: ты не в курсе, зачем он SysRq отключал в своих сборках 2.6 ?
<UlfR> rider: не в курсе. Он наверное его просто не включал :)
<rider> UlfR: ;-)
* rider готовит среду для сборки 2.6.2 в Sisyphus
<ab> vsu: они там не сломаны, а забиты намертво и изменяются посредством MODPATH
<ab> rider: у нас уже давно все готово
<rider> ab: не.. пока это не в Sisyphus - это не готово.. а я говорю про наш ядерный CVS ;-)
<vsu> ab: а вот параметра для перекрытия версии ядра там всё равно не хватает
<rider> ab: очень не хотелось бы делать fork modutils ;-(
<ab> vsu: можно обойтись в MODPATH прямым указанием.
<ab> rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т
<rider> ab: почему ?
<ab> rider: я уже объяснял почему. Посмотри выше
<vsu> ab: нет, они именно сломаны
<vsu> ab: в /etc/modutils.d/* они работают
<rider> ab: как тогда живет RH, просто объединяя в один бинарник mit и modutils, но при этом не расширяя функциональность mit ?
<ab> vsu: ты говоришь про переназначение в конфигурационном файле, а я про переменные среды.
<vsu> ab: а вот в modules.conf уже нет
<ab> rider: у RH еще нет дистрибутива на 2.6. И видимо, они не сильно используют макросы
<vsu> ab: так вопрос был "зачем depmod конфигурационный файл?"
<rider> ab: на самом деле макросы практически никто не использует ;-(
<rider> ab: и мы в том числе
<ab> rider: дело в том, что даже смотря в код RH AS 2.1 я не обнаружил нормального использования modutils.
<rider> ab: дык его нигде нет
<vsu> ab: а version override всё-таки нужен - иначе есть вероятность, что mkinitrd будет работать неправильно
<ab> rider: и что ты предлагаешь? Выкинуть все нафиг? 
<vsu> ab: как раз при активном использовании макросов
<ab> vsu: я согласен, что последнее нужно. Вопрос в том, _зачем_ ради этого все переделывать в рамках mit?
<vsu> ab: почему всё?
<UlfR> vsu: ну можно чуть подправить depmod, можно конечно version override добавить
<rider> ab: я думаю ;-)
<ab> vsu: или я не понимаю, что вы с Антоном говорите, или вы говорите что-то неформализованное
<vsu> ab: например, какая разница между реализациями insmod? обе тупые
<vsu> ab: вот и предлагается вместо толстых патчей просто цеплять insmod из mit
<ab> vsu: так ты так и говори сразу, а не "вообще есть мнение, что добавлять всё-таки надо не так" и ссылаться на совсем иное
<rider> ab: нам надо по хорошему сделать максимально простой поддержку своих modutils и mit объединенных.. 
<ab> rider: вообще Глеб сейчас родил идею:
<ab> "Для чего нам нужны макросы"
<rider> ab: что бы не тратить время на портирование патчей
<rider> ab:  и ?
<ab> "Для того, чтобы на уровне modules tools разбирать конфигурации машин автоматически и описывать их только вхождениями в /etc/modutils.d/"
<ab> Так, для каждого типа, скажем, Максов, будет свой отдельный файл конфигурации -- набор макросов. И все, остальное автоматом поднимется
<ab> далее вся эта толпа внутри файлов обвязана if `host_type` == m5wide .... 
<rider> ab: ой ужас
<rider> ab: остановись !!!
<vsu> ab: и всё это разбирается в runtime????
<vsu> ab: ещё include `host_type` напиши :)
<ab> :-)
<UlfR> vsu: rider: а чем не нравится-то? :)
<rider> UlfR: всем !!! Начиная с того, что мне придется поддерживать плафтормы, и заканчивая тем - что все равно придется делать детект железа.
<ab> vsu: по поводу разборок -- скорость загрузки модулей не так критична на самом деле.
<rider> ab: ты не прав ;-)
<ab> rider: ты все равно поддерживаешь платформы.
<rider> ab: вот это не критично и то не критично.. а в итоге все тормозит.. 
<rider> ab: а зачем делать двойную работу, добавляя конфиги для платформ и одновременно разрабатывая средства для детекта железа ?
<ab> rider: мне не нравится генератор конфигурации типа configure, потому что он описывает на самом деле не платформу, а некоторую среднюю температуру по больнице.
<vsu> ab: а что, куча if это опишет лучше?
<rider> ab: конфиги для платформ мы можем вынести в генератор конфигурации, который будет детектить платформу и тюнить конфиг под нее.. это по моему просто ;-)
<ab> vsu: смотри на это как на case :-)
<rider> ab: вы что там пили сегодня ? ;-)
<vsu> ab: или куча if в modules.conf лучше, чем такая же куча в something.sh/.pl/.rb/...?
<UlfR> vsu: rider: ну да согласен, пример не очень :)
<rider> UlfR: ;-)
<ab> rider: квас нормальный :-)
<rider> UlfR: в итоге пришли к тому, что никто не знает для чего нужны платформы ;-)
<ab> rider: что пил UlfR -- не знаю :-)
<rider> ab: хорошо хоть не лимонник ;-)
<rider> тьфу ты.
<UlfR> :)
<rider> заговорился
<gvy> rider, ты того, полегче ;-)
<rider> в итоге пришли к тому, что никто не знает для чего нужны макросы
<ab> rider: у тебя получается не платформа, а размазня.
<rider> ab: в смысле ?
<ab> vsu: rider: что касается скорости, то с m-i-t (оригинальными) она сильно ниже, поскольку на каждый чих он запускает system
<gvy> макросы для платформ -- идея здравая.  так у нас _вообще_ нет средств поддерживать специфические наборы хреновин, которые по случайному совпадению часто оказываются упакованными в один корпус
<rider> ab: у меня будет лежать отдельный конфиг типа "m5wide.conf" - чем он тебе не нравится ?
<ab> rider: и чем он отличается от /etc/modutils.d/m5wide.conf ?
<mouse> ab:  :)
<gvy> mouse, ! :
<rider> ab: всем ;-) 
<rider> ab: начиная с формата ;-)
<rider> ab: и заканчивая тем, что описывать будет необходимо только специфические для платформы вещи
<rider> ладно, давайте подумаем - для чего еще нужны макросы ;-)
<ab> rider: Понимаешь, так ты теряешь информацию на уровне modules tools о платформе.
<rider> ab: а она мне там не нужна !
<vsu> ab: что - всё описание платформы влезет в modules.conf?
<ab> vsu: вполне.
<rider> vsu: одной платформы - может быть влезет.. не все конечно, но многие вещи
<rider> vsu: а вот когда этих платформ двадцать ?
<ab> vsu: просто постарайся подумать об этом без предубеждения.
<ab> rider: и 20 влезут без проблем. Точнее, не будут использоваться, когда не надо.
<vsu> ab: а `host_type` ты собираешься внутрь modutils вхачить? или бужешь по каждому поводу popen дёргать?
<ab> vsu: я -- ничего не собираюсь. Ты бы видел, сколько там "вхачено"
<vsu> ab: ага... похоже, именно поэтому его и решили переписать нафиг
<ab> vsu: естественно. Но при этом выплеснули ребенка
<ab> vsu: я был бы рад, если бы m-i-t делали две вещи:
<ab>  - поддерживали бы старый формат модулей
<ab>  - использовали бы макросы 
<ab> нормальные макросы
<ab> вот и все. 
<vsu> ab: а написание "modutils 2.5.x" так и сдохло?
<ab> vsu: оно выродилось в то, что сделал Rusty
<rider> ab: не, мне эта идея не нравится ;-(
<rider> ab: так пинайте автора mit, тем более патчи уже есть
<ab> rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал
<ab> rider: и я с ним согласен.
<rider> ab: ты про то, что пускай все делают обертки сами ?
<ab> он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны
<ab> rider: да
<ab> он сделал все, чтобы облегчить нам работу.
<rider> ab: это все хорошо, но зачем нам тогда себе большой гемморой на тему отслеживания изменений в modutils и mit и синхронизации этих изменений ? Сколько времени уйдет у vsu при выходе каждой версии на просмотр diff'а и доработке нашей версии ?
<ab> rider: я свое мнение высказал немного выше. Оно основано на анализе того, что есть сейчас.
<ab> rider: Глебу получилось проще написать патч к modutils -- он меньше, чем портирование аналогичного кода в mit
<ab> rider: возможно, наоборот (добавление нужного функционала в м-и-т) будет проще поддерживать, пусть и с большим объемом кода
<UlfR> ab: не совсем так. Он меньше чем mit+федоровский_патч
<ab> rider: факт в том, что код в modutils еще можно протолкнуть, поскольку обоснование можно построить на вполне твердой почве (2.2+2.4+2.6 в одном _уже_ использующемся продукте), а вот добавлять что либо в эксперимент под названием m-i-t не получится -- автор уже высказал свое мнение
<ab> rider: в результате остается два пути: 
<ab>  - развивать направление, начатое Глебом
<ab>  - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils
<ab> Второй вариант, при грамотной реализации, может быть принят остальными вендорами.
<ab> vsu: суть в том, что текущий наш modutils решает тактические проблемы лучше федориного. Стратегически, лучше развивать второй вариант и стандартизировать его
<rider> ab: я сильно в этом сомневаюсь... 
<rider> ab: я про вендоров
<gvy> а в lkml спрашивали?  или все здесь только?
<ab> rider: я сомневаюсь меньше. На здравые идеи они реагируют нормально. Все, что уменьшает уровень лишнего бардака, принимается вполне быстро
<rider> ab: кто будет заниматься этим вопросом ?
<ab> gvy: нет. Это не совсем то место для обсуждения дистрибутивных проблем.
<ab> rider: главная проблема сейчас в том, что _никто_ не сформулировал проблему. Все пытаются обходить реальность, порожденную предыдущими обходами
<gvy> ab, какие ж они дистрибутивные?
<ab> rider: не знаю.
<gvy> они как минимум метадистрибутивные
<gvy> и имеющее прямое отношение к
<ab> gvy: дистрибутивные. Это для дистрибутива важно, чтобы у него единообразно все было
<ab> gvy: я имею в виду дистрибутивные в противовес разработке ядра
<rider> ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ?
<ab> rider: нет, так не пойдет -- это глупо.
<ab> rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами.
<rider> ab: почему ? modutils из fedora вполне неплохой.
<ab> rider: еще раз -- у него унифицированный макроязык для всех ядер?
<rider> ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность
<rider> ab: а зачем ?
<rider> ab: естественно нет
<ab> rider: я не вижу от него вопросов по патчам.
<rider> ab: а они их никогда не задает. ;-)
<ab> rider: тогда какой толк от федориных modutils.
<rider> ab: ты же знаешь ldv ;-)
<ab> rider: задает. Это ты его не знаешь.
<rider> ab: они выполняют свою работу - грузят и выгружают модули ;-)
<ab> не переводи серьезную тему в шутку
<ab> rider: в вопросах по патчам "сомнениям" не место -- либо конкретные претензии, либо какие могут быть претензии? :-)
<rider> ab: я не перевожу, я тебе вполне серьезно говорю - они выполняют свою работу с модулями. навешивать на них функциональность по детекту железа IMHO бесмысленно
<vsu> rider: кстати, если действительно делать унифицированный язык, придётся менять и старую функциональность
<rider> vsu: почему ?
<ab> rider: при чем здесь "детект железа"?
<vsu> rider: там две вещи: '-'/'_' и fnmatch
<ab> rider: такое ощущение, что ты путаешь проблемы
<rider> ab: я у тебя спрашивал уже - зачем нам нужен макроязык. Ты мне сказал для чего ?
<vsu> rider: а иначе мы получим, что один и тот же файл с разными ядрами обрабатывается совершенно по-разному
<ab> rider: то, что я тебе сказал сегодня -- идея Глеба, которую я просто озвучил. Он от нее уже отказался.
<rider> ab: ясно
<rider> ab: зачем еще нам нужен макроязык ?
<rider> vsu: понятно
<vsu> rider: именно из-за этого я выбросил вчерашний вариант (ну, не совсем выбросил... но почти)
<ab> rider: для унификации настроек в рамках единой информационной среды (учить разные подходы при работе с разными ветвями ядер неэффективно).
<vsu> rider: т.е. фактически это получается как раз что-то вроде "modutils 2.5.x" - с потенциальной несовместимостью
<ab> rider: я пытаюсь уменьшить энтропию хотя бы в этом конкретном месте (работа с ядрами). Она (энтропия) настолько высока, что пользователи буквально захлебываются в ней. Мне не составляет проблемы настроить так, чтобы обе ветви ядер работали у меня на машине нормально, потому что я помню все и держу всю информацию в голове. Но это не дистрибутивный подход.
<rider> ab: а зачем нам нужна эта унификация ?
<rider> ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ?
<rider> ab: она же сможет детектить версию ядра
<rider> ab: т.е. - перенести макроязык в свое приложение, оторвав зависимость от modutils.
<rider> ab: один черт придется что-то подобное ваять ;-(
<UlfR> rider: тогда уж точно не нужны федорины патчи, имхо лучше тогда два пакета mu и mit_с_обвязкой разрулить при помощи rmp
<UlfR> rpm т.е.
<ab> rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож
<ab> но добиться унификации 
<rider> UlfR: можно и так.. федорины патчи хороши тем, что практически ничего не меняют
<rider> ab: пользователь, по хорошему, вообще не должен знать ничего о mit и modutils ;-)
<ab> rider: они меняют главное -- методику работы с ядрами для пользователя. Мне все равно, что внутри они "красивые" -- они вносят слишком много несовместимости
<UlfR> rider: тогда толку от них если они ничего не меняют? :)
<ab> rider: мы по-разному понимаем этот термин
<rider> ab: какой из них ? ;-)
<ab> rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д.
<ab> rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д.
<rider> ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот
<rider> ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная.
<rider> ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. 
<ab> rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. 
<ab> rider: потому что они не делают appliances :)
<ab> rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале.
<rider> ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях
<ab> rider: просто подумай о аналогичной вещи -- мы были _первые_ кто подумал завести нормально дистрибутив нативно на arm.
<rider> ab: какой дистрибутив ? Где он ?
<ab> rider: Эх. Глупо.
<ab> rider: у Интела на ftp :-)

[skip]

<rider> ab: ты не уходи от важного разговора.
<rider> ab: вы займетесь modutils-ng ?
<ab> rider: я уже все сказал по поводу modutils. 

[skip]

<rider> ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры)
<ab> rider: прямо сейчас я урл дать не могу, на этой неделе будет Intel Developers Forum, где его будут демонстрировать
<ab> rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам.

[skip]

<rider> ab: продолжим с IDE в ядер ? ;-)
<rider> ab:  у меня был ряд вопросов по выносу IDE в модули.. 
<ab> rider: поговори об этом с tren и ed через недельку.
<rider> ab: недельку.. за недельку все может поменятся.. 
<rider> ab: я не совсем понимаю как мы сделаем так, что бы пользователи могли харды переставлять из одной машины в другую.. ;-(
<ab> rider: еще раз: поговори с теми, кто это делает, а не со мной. Они сейчас в отпуске.
<rider> ab: дык ты же меня уговаривал на прошлой неделе вынести модули IDE из ядер... пропатчив все что детектит
<ab> rider: потому что на прошлой неделе все были здесь и были готовы разговаривать на эту тему и делать эту работу. То, что ты отреагировал не на следующий день, как обещал, а через неделю -- увы, сейчас их нет.
<rider> ab: у меня были другие дела ;-(
<ab> теперь у нас другие :-(
<ab> Мне сегодня нужно security updates собирать, а я с тобой здесь спорю. :-(
<rider> UlfR: ладно, ab ушел от ответственности... ты то что скажешь про modutils, ты же патчил - знаешь сложность создания патчей.. да и зачем нужен макроязык тоже знаешь ;-)
<rider> ab: а я уже собрал свой
<ab> rider: что ты собрал?
<gvy> rider, а с каких пор это в сизифе (и у тебя) стало котироваться "как у всех"?
<gvy> это серьезный вопрос -- что главнее: "как у всех" или "правильно"?
<gvy> rider, и начсет унификации -- "даешь унификацию макросов rpm!", а остальное уж как-то по мелочам утрясется
<gvy> хотя это -- ключевая точка для девелоперов, которых меньше, но принцип (наблюдаемый) один
<rider> ab: kernel-image-vs-smp
<gvy> он даже был сформулирован ldv и занесен в фортунки
<rider> gvy: тут немного о другом спор идет, хотя я тоже сторонник унификации макросов ;-)
<rider> gvy: я имею в виду междистрибутивную унификацию
<rider> gvy: я думаю, что мы когда-нить получим унификацию макросов.. хотя я могу и ошибаться.
<gvy> rider, я прекрасно понимаю.  но в данном случае на 100% согласен с ab (вовсе не из позиции вида "все, что сказал rider -- чушь и его надо кунуть").
<gvy> rider, попросту говоря -- если я что-то задвигал в апстримы, то как раз *на основании* обкатки в дистро
<gvy> а тут -- критичный компонент
<gvy> ab, rider -- но в lkml однозначно надо отсигналить.  всякую ^&*^&* обсуждать время им есть -- значит, на важный (вроде этого) вопрос тоже найдется
<rider> gvy: я тоже согласен с ab, но ресурс на это выделять тяжело
<gvy> rider, а если оно уже?
<rider> gvy: судя по словам ldv оно еще далеко не уже
<UlfR> rider: отрезать язык -- не добавить. я сразу отписывал, что варианта два. 1. патчить mu и вести их, 2. патчить mit и вести их. По сложности -- примерно одинаково. Про тактику и стратегию развития mu/mit Саша уже говорил. Ну конечно есть вариант вообще ничего не делать -- типа само утресётся.
<lioka> gvy: да какая разница, что там думает lkml ? ненулевое количество пользователей alt-based distro консоли-то не видят. И это число, к прискорбию, будет увеличиваться.
<gvy> lioka, это еще один довод, но они как раз ничего и не решают, так?
<rider> UlfR: может быть третий вариант и выбрать, параллельно добивая авторов modutils и mit до унификации ?
<rider> gvy: это не довод ;-(
<gvy> rider, практика показывает, что утрясается обычно хуже, чем хотелось.  заметь, иначе бы нам тут и говорить было не о чем
<lioka> решают те, кто саппортит. 
<ab> rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. 
<gvy> именно, в итоге
<UlfR> ab: согласен
<Grigory> Тут я уже видел apt для RH. Ждем? :-)
<rider> gvy: давай я в тебя брошу новую версию mit и ты ее синхронизируешь с modutils... я просто не понимаю, зачем нам нужна _реально_ никому не нужная функциональность ?
<lioka> а 'майнстримового' саппорта не бывает. period
<gvy> rider, не надо в меня всяким бросаться
<UlfR> rider: новую это какую?
<gvy> rider, функциональность, про которую говорит ab -- нужна им и нужна мне.  чем плохо забивать на партнеров и их мнение -- лучше не будем вспоминать
<ab> rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов.
<rider> UlfR: module-init-tools-0.9.15-pre4.tar.bz2
<UlfR> rider: это не новая ;)
<rider> gvy: расскажи хоть ты мне - зачем тебе нужен макроязык ?
<rider> UlfR: ;-)
<gvy> rider, вспомни -- есть железки, которые "в розницу" (по компонентам, выуживая с pci) вроде и получается настроить -- да только из-за специфических ляпов _в сумме_ оно не работает
<rider> UlfR: значит ту, которая не вышла ;-)
<ab> rider: у меня последняя module-init-tools-3.0-pre9.tar.bz2
<rider> gvy: ну и что, а макоязык тут при чем ?
<rider> Упс, действительно уже есть 3.0-pre9
<gvy> rider, сделай еще как-то.  я просто знаю, что ab и Grigory про это думают, а ты -- перегружен
<gvy> rider, и в итоге часто допускаешь ошибки по таким точкам
<rider> gvy: мы делаем, потому и перегружены
<rider> gvy: ладно, бог с ним.. еще для чего нужен макроязык ?
<gvy> rider, ну так делать-то надо то, чего нет или что есть недоделанное
<gvy> минчанам надо -- пусть сделают, они-то на команду оглядываются
<rider> gvy: мы делаем то, что считаем нужным.
<rider> gvy: для наших клиентов
<rider> gvy: ладно, зачем еще макроязык нужен ?
<gvy> rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка)
<rider> gvy: а зачем ?
<gvy> в течение жизненного цикла 2.4
<rider> gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ?
<rider> gvy: еще зачем ?
<gvy> для _единообразной_ поддержки.
<gvy> rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине:
<rider> gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ?
<gvy> ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор;
<gvy> они будут или _знать_ про то, как это было с 2.4 (=> опытные),
<rider> gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться.
<gvy> или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...)
<gvy> так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет
<rider> gvy: я не понял про YaST
<gvy> сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4"
<rider> gvy: ;-) 
<gvy> rider, ну, "те, которые консоли не видят" (которым в общем пофиг, лишь бы работало)
<gvy> понимаешь?
<rider> gvy: ты посмотри сначала на разницу между modutils и mit ;-)
<gvy> rider, я смотрел где-то при 2.5
<ab> gvy: на самом деле, как это с 2.2, а то и раньше.
<gvy> rider, и если ты не в курсе -- собирал m-i-t 
<gvy> пакетил
<rider> gvy: ;-)
<gvy> и уже по N-му кругу думаю над этими граблями
<gvy> потому что тогда тоже обнюхивал, как в cooker/rawhide/pld
<gvy> понимаешь? ;-)
<gvy> ab, отож. 
<gvy> rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим
<gvy> а эти идиоты полромали -- ну так это проблемы _их_ клиентов
<rider> gvy: а нам думать уже все.. некогда ;-( Время ушло на раздумья. Подумали, хватит ... есть мантейнер - пускай принимает решение. А пакет на этой неделе должен быть в Sisyphus в рабочем виде 
<gvy> rider, мож я ослеп, но то, что на people/ed/ -- у меня дома и в конторе работает
<gvy> надо посмотреть, где мог костылями подпирать, пока алиасов не наделали...
<rider> gvy: оно у меня тоже работает - иди докажи это ldv
<ab> rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан.
<ab> rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт.
<gvy> rider, а где можно ознакомиться с претензиями ldv?  в devel-kernel@ было?
<rider> ab: верю, сам на нем сижу.. иди доказывай это ldv. 
<rider> ab: и пакета в Sisyphus тоже нет
<gvy> rider, ну позови его сюда, что ли
<gvy> :-)
<rider> gvy: зови сам, мне это нахрен не нужно.... 
* rider is away: Я занят
<vsu> gvy: а багов в том патче есть... как, впрочем, и в чистом mit
<ab> rider: я не собираюсь доказывать ничего тому, кто не хочет обсуждать. Это пагубная практика. Я только от тебя узнал, что он в этих патчах "сомневается".
<gvy> rider, попробую по крайней мере написать всем почтой
<gvy> vsu, баги всегда есть
<ab> vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится.
<gvy> точнее, я сейчас этот кусок перешлю в d-k@
<ab> vsu: факт в том, что пакет работает, в том числе и со старыми ядрами. Проблем с ними не замечено.
* lioka .oO (rider занят. мы -- так, шаро$#%мся)
<gvy> lioka, да=-да, вот именно
<-- rider has quit ("Вышел из XChat")
* ab в расстроенных чувствах собирается домой. Через час.
<UlfR> vsu: так млин, написали бы, где -- пофиксили бы...
<vsu> UlfR: точнее, там кое-где изврат какой-то написан - работает правильно, но... а вот в get_kernel26_info заложена мина
<UlfR> vsu: "там кое-где изврат какой-то написан" -- где можно, я подумаю как это сделать нормально. мина в чём?
<vsu> UlfR: ldv особо понравился код if (obj_find_section(f, "__ksymtab_strings") != NULL) и то, что дальше :)
<vsu> UlfR: а мина - n_module_stat = nmod = ret = 256; //временно
<UlfR> vsu: мину разминировать? 
<vsu> UlfR: я этот кусок переписал, но ещё не пробовал - сейчас кину
--> rider (~rider@altlinux.balabanovo.ru) has joined #altlinux
<gvy> ab, UlfR, vsu, rider -- никто от вышесказанного не отказывается?  дочищу и в d-k@
<gvy> чтоб Диме было на что ссылаться
<vsu> UlfR: поймал?
<vsu> UlfR: да ладно, в mit ошибки ещё более классические :)
<UlfR> vsu: ну с миной понятно, но чем так if (obj_find_sec... понравился? 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] q: modutils vs module-init-tools

[Anton Farygin]

On Mon, Feb 09, 2004 at 07:19:01PM +0200, Michael Shigorin wrote:
> 	Здравствуйте.
> Сегодня на #altlinux имели место очередные прения.
> 
> Лог прилагаю; по возможности извлеку из него ключевые моменты.
> 
> Фактически обсуждалось:
> 
> - каким (и когда) modutils быть в Sisyphus
> - важно ли, чтобы они были "как у всех".
> 
> Мнение группы ab, UlfR, lioka, Grigory и вашего покорного слуги
> вкратце сводится к "надо, чтоб работало и поддерживалось; как у
> других -- дело десятое".  Вывод -- взять modutils имени UlfR из
> people/ed/.
> 
> Мнение rider (отчасти при поддержке vsu и со ссылками на ldv)
> рискну просуммировать как "нам вдруг стало небезразлично, как там
> что в Fedora и SuSE".  Вывод -- тащить modutils из Fedora.

1. Не тащить из Fedora, а собрать по аналогии. Ибо их решение мне
понравилось (я про это уже говорил).

Хотя это равнозначно по своей сути сборке двух отдельных пакетов, как оно
изначально и задумывалось автором module-init-tools.

> 
> Субъективно -- последнее выглядит интересным исключением из
> типично наблюдаемых в течение ряда последних лет тенденций
> развития Sisyphus как оригинального репозитория с вагоном
> know-how, из которого получаются удобные и выгодные в
> долговременной эксплуатации продукты.

Для долговременной и успешной поддержки некоего симбиоза из ужа с ежом нам
на работу срочно требуется десяток профессиональных генетиков со стажем
работы.

> 
> 2 ldv: какие проблемы с modutils-2.4.25-alt16?
> 
> PS: субъективно -- "тащить федорино горе" есть безумие, потому
> как это вовсе не редхат, и бултыхаются они сейчас в проблемах
> нашей трехлетней давности, судя по fedora-package-announce@.
> Смотреть на них в таком системообразующем вопросе -- глупо и
> смешно.  А отказываться от проверенного варианта в пользу
> концепт-кара с "простым" (нафигнужным) патчем -- безумие.

Хорошо. Давайте тогда соберем два отдельных пакета, как сделано в Debian и
не будем тратить время и силы на изобретение велосипеда.

> 
> ---
> 
> <UlfR> vsu: надобы свести воедино modutils. Я таки добавил *.inputmap
> 
> <vsu> UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils
> <UlfR> vsu: тогда какие предложения? 
> <vsu> UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools
> <ab> vsu: Мы теряем главное -- макроязык
> 
> <ab> vsu: он (м-и-т) вообще покоцанный, это не показатель.
> <ab> vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг"
> 
> <rider> ab: просто у меня возникает ощущение, что мы делаем что-то не то.. 
> <vsu> ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :(
> 
> <rider> ab: очень не хотелось бы делать fork modutils ;-(
> <ab> rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т
> 
> <vsu> ab: а написание "modutils 2.5.x" так и сдохло?
> <ab> vsu: оно выродилось в то, что сделал Rusty
> <rider> ab: так пинайте автора mit, тем более патчи уже есть
> <ab> rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал
> <ab> rider: и я с ним согласен.
> <rider> ab: ты про то, что пускай все делают обертки сами ?
> <ab> он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны
> 
> <ab> rider: в результате остается два пути: 
> <ab>  - развивать направление, начатое Глебом
> <ab>  - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils
> <ab> Второй вариант, при грамотной реализации, может быть принят остальными вендорами.
> 
> <rider> ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ?
> <ab> rider: нет, так не пойдет -- это глупо.
> <ab> rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами.
> <rider> ab: почему ? modutils из fedora вполне неплохой.
> <ab> rider: еще раз -- у него унифицированный макроязык для всех ядер?
> <rider> ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность
> <ab> rider: я не вижу от него вопросов по патчам.
> 
> <rider> ab: а зачем нам нужна эта унификация ?
> <rider> ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ?
> <ab> rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож
> <ab> но добиться унификации 
> [skip]
> <ab> rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д.
> <ab> rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д.
> <rider> ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот
> <rider> ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная.
> <rider> ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. 
> <ab> rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. 
> <ab> rider: потому что они не делают appliances :)
> <ab> rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале.
> <rider> ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях
> 
> <rider> ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры)
> <ab> rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам.
> 
> <lioka> решают те, кто саппортит. 
> <ab> rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. 
> <gvy> именно, в итоге
> <UlfR> ab: согласен
> <Grigory> Тут я уже видел apt для RH. Ждем? :-)
> <lioka> а 'майнстримового' саппорта не бывает. period
> 
> <ab> rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов.
> 
> <rider> gvy: ладно, зачем еще макроязык нужен ?
> <gvy> rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка)
> <gvy> в течение жизненного цикла 2.4
> <rider> gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ?
> <gvy> для _единообразной_ поддержки.
> <gvy> rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине:
> <rider> gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ?
> <gvy> ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор;
> <gvy> они будут или _знать_ про то, как это было с 2.4 (=> опытные),
> <rider> gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться.
> <gvy> или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...)
> <gvy> так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет
> <rider> gvy: я не понял про YaST
> <gvy> сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4"
> [skip]
> <gvy> rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим
> <gvy> а эти идиоты полромали -- ну так это проблемы _их_ клиентов
> 
> <ab> rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан.
> <ab> rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт.
> <gvy> rider, а где можно ознакомиться с претензиями ldv?  в devel-kernel@ было?
> <rider> ab: верю, сам на нем сижу.. иди доказывай это ldv. 
> 
> <vsu> gvy: а багов в том патче есть... как, впрочем, и в чистом mit
> <gvy> vsu, баги всегда есть
> <ab> vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится.
> 
> -- 
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>   ------ Linux.Kiev http://www.linux.kiev.ua/

> --> vsu (~vsu@mivlgu.ru) has joined #altlinux
> <vsu> $@#$%#$#%@#$%#$#$@ detectloader!!!
> <UlfR> vsu: 
> <vsu> UlfR: 
> <UlfR> vsu: надобы свести воедино modutils. Я таки добавил *.inputmap
> <vsu> UlfR: вообще есть мнение, что добавлять всё-таки надо не так
> <UlfR> vsu: ?
> <vsu> UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils
> <UlfR> vsu: тогда какие предложения? 
> <vsu> UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools
> <vsu> UlfR: insmod в принципе тоже
> <vsu> UlfR: т.е. фактически сильно патчить нужно только modprobe
> <ab> vsu: зачем? 
> <ab> vsu: Мы теряем главное -- макроязык
> <vsu> ab: так макроязык как раз весь в modprobe
> <ab> vsu: и в depmod
> <vsu> ab: pcimapfile=...?  так он и для 2.4, похоже, уже сломан
> <ab> vsu: не только. Там больше.
> <vsu> ab: что именно?
> <UlfR> vsu: всё что *file
> <UlfR> vsu: generic_stringfile, depfile, ..., prune
> <ab> vsu: он линкуется с config_read, соответственно, читает конфигурационный файл и парсит все
> <vsu> UlfR: ну и кому оно нужно?  это уже сейчас сломано, и никто не заметил
> <ab> vsu: заметили. Это отлично видно на новом hotplug
> --> rider_ (~rider@altlinux.balabanovo.ru) has joined #altlinux
> <vsu> ab: а что, новый hotplug хочет засовывать эти файлы куда-то в другое место?
> <gvy> rider_, ! :)
> <ab> vsu: суть не в "засовывать", а в "использовать". Новый хотплаг использует много.
> <ab> vsu: в частности, умеет использовать input
> <rider_> hi ppl
> --- rider_ is now known as rider
> <vsu> ab: т.е. ему нужен /lib/modules/`uname -r`/modules.input (или как там он точно называется)?
> <ab> vsu: inputmap
> <rider> ab: замечания по Max'у ?
> <vsu> ab: ну и каким боком здесь макроязык?  depmod и без него этот файл сделает
> <rider> ab: ааа.. да, есть такое дело.. сейчас перешлю
> <ab> vsu: при том, что depmod не будет работать, если не сможет распарсить основной конфиг.
> <ab> vsu: вообще не будет работать.
> <vsu> ab: depmod из module-init-tools вообще в конфиг не смотрит
> <ab> vsu: он (м-и-т) вообще покоцанный, это не показатель.
> <ab> vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг"
> <vsu> ab: вообще реально все эти path и *file из modules.conf кому-нибудь нужны?
> <ab> vsu: да
> <ab> vsu: в частности, для сосуществования межархитектурных карт (32/64)
> <vsu> ab: и куда они в подобном случае показывают?
> <rider> ab: ушел
> <ab> vsu: обычно они показывают в значения по умолчанию, но при помощи MODPATH их можно переопределить
> <rider> ab: а вы не писали автору module-init-tools и автору modutils письмо с патчем, объединяющим функциональность ?
> <ab> rider: UlfR что-то писал
> <rider> UlfR: а ответ пришел ?
> <UlfR> rider: он в отпуске был
> <rider> ab: просто у меня возникает ощущение, что мы делаем что-то не то.. 
> <UlfR> на неделе отпишу ещё раз
> <vsu> ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :(
> <rider> UlfR: отпиши плз
> <rider> vsu: именно ;-(
> * mouse is back (gone 93:22:07)
> <mouse> rider: vsu
> <mouse> UlfR: 
> <mouse> ab: hi
> <vsu> mouse: 
> <rider> mouse: привет ! ты куда пропал ?
> <UlfR> mouse: 
> <ab> vsu: объясни мне, _зачем_ идти следом за Расти в его упрощениях, если при этом теряется основной функционал, а он сам заявляет: "я специально делаю проще, чтобы другие могли сделать как надо для них"
> <rider> ab: так может быть и сделать так как надо нам, но не патчами, а оберткой над module-init-tools ?
> <vsu> ab: покажи, кому реально нужен этот функционал именно в depmod
> <vsu> ab: по поводу modprobe я как раз не спорю
> <vsu> ab: и то - *path там и для 2.4 уже сколько времени сломаны, и никто не замечает. значит, не нужны
> <rider> UlfR: ed'а нет сегодня ?
> <UlfR> rider: нет он в отпуске на недельку
> <rider> UlfR: ты не в курсе, зачем он SysRq отключал в своих сборках 2.6 ?
> <UlfR> rider: не в курсе. Он наверное его просто не включал :)
> <rider> UlfR: ;-)
> * rider готовит среду для сборки 2.6.2 в Sisyphus
> <ab> vsu: они там не сломаны, а забиты намертво и изменяются посредством MODPATH
> <ab> rider: у нас уже давно все готово
> <rider> ab: не.. пока это не в Sisyphus - это не готово.. а я говорю про наш ядерный CVS ;-)
> <vsu> ab: а вот параметра для перекрытия версии ядра там всё равно не хватает
> <rider> ab: очень не хотелось бы делать fork modutils ;-(
> <ab> vsu: можно обойтись в MODPATH прямым указанием.
> <ab> rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т
> <rider> ab: почему ?
> <ab> rider: я уже объяснял почему. Посмотри выше
> <vsu> ab: нет, они именно сломаны
> <vsu> ab: в /etc/modutils.d/* они работают
> <rider> ab: как тогда живет RH, просто объединяя в один бинарник mit и modutils, но при этом не расширяя функциональность mit ?
> <ab> vsu: ты говоришь про переназначение в конфигурационном файле, а я про переменные среды.
> <vsu> ab: а вот в modules.conf уже нет
> <ab> rider: у RH еще нет дистрибутива на 2.6. И видимо, они не сильно используют макросы
> <vsu> ab: так вопрос был "зачем depmod конфигурационный файл?"
> <rider> ab: на самом деле макросы практически никто не использует ;-(
> <rider> ab: и мы в том числе
> <ab> rider: дело в том, что даже смотря в код RH AS 2.1 я не обнаружил нормального использования modutils.
> <rider> ab: дык его нигде нет
> <vsu> ab: а version override всё-таки нужен - иначе есть вероятность, что mkinitrd будет работать неправильно
> <ab> rider: и что ты предлагаешь? Выкинуть все нафиг? 
> <vsu> ab: как раз при активном использовании макросов
> <ab> vsu: я согласен, что последнее нужно. Вопрос в том, _зачем_ ради этого все переделывать в рамках mit?
> <vsu> ab: почему всё?
> <UlfR> vsu: ну можно чуть подправить depmod, можно конечно version override добавить
> <rider> ab: я думаю ;-)
> <ab> vsu: или я не понимаю, что вы с Антоном говорите, или вы говорите что-то неформализованное
> <vsu> ab: например, какая разница между реализациями insmod? обе тупые
> <vsu> ab: вот и предлагается вместо толстых патчей просто цеплять insmod из mit
> <ab> vsu: так ты так и говори сразу, а не "вообще есть мнение, что добавлять всё-таки надо не так" и ссылаться на совсем иное
> <rider> ab: нам надо по хорошему сделать максимально простой поддержку своих modutils и mit объединенных.. 
> <ab> rider: вообще Глеб сейчас родил идею:
> <ab> "Для чего нам нужны макросы"
> <rider> ab: что бы не тратить время на портирование патчей
> <rider> ab:  и ?
> <ab> "Для того, чтобы на уровне modules tools разбирать конфигурации машин автоматически и описывать их только вхождениями в /etc/modutils.d/"
> <ab> Так, для каждого типа, скажем, Максов, будет свой отдельный файл конфигурации -- набор макросов. И все, остальное автоматом поднимется
> <ab> далее вся эта толпа внутри файлов обвязана if `host_type` == m5wide .... 
> <rider> ab: ой ужас
> <rider> ab: остановись !!!
> <vsu> ab: и всё это разбирается в runtime????
> <vsu> ab: ещё include `host_type` напиши :)
> <ab> :-)
> <UlfR> vsu: rider: а чем не нравится-то? :)
> <rider> UlfR: всем !!! Начиная с того, что мне придется поддерживать плафтормы, и заканчивая тем - что все равно придется делать детект железа.
> <ab> vsu: по поводу разборок -- скорость загрузки модулей не так критична на самом деле.
> <rider> ab: ты не прав ;-)
> <ab> rider: ты все равно поддерживаешь платформы.
> <rider> ab: вот это не критично и то не критично.. а в итоге все тормозит.. 
> <rider> ab: а зачем делать двойную работу, добавляя конфиги для платформ и одновременно разрабатывая средства для детекта железа ?
> <ab> rider: мне не нравится генератор конфигурации типа configure, потому что он описывает на самом деле не платформу, а некоторую среднюю температуру по больнице.
> <vsu> ab: а что, куча if это опишет лучше?
> <rider> ab: конфиги для платформ мы можем вынести в генератор конфигурации, который будет детектить платформу и тюнить конфиг под нее.. это по моему просто ;-)
> <ab> vsu: смотри на это как на case :-)
> <rider> ab: вы что там пили сегодня ? ;-)
> <vsu> ab: или куча if в modules.conf лучше, чем такая же куча в something.sh/.pl/.rb/...?
> <UlfR> vsu: rider: ну да согласен, пример не очень :)
> <rider> UlfR: ;-)
> <ab> rider: квас нормальный :-)
> <rider> UlfR: в итоге пришли к тому, что никто не знает для чего нужны платформы ;-)
> <ab> rider: что пил UlfR -- не знаю :-)
> <rider> ab: хорошо хоть не лимонник ;-)
> <rider> тьфу ты.
> <UlfR> :)
> <rider> заговорился
> <gvy> rider, ты того, полегче ;-)
> <rider> в итоге пришли к тому, что никто не знает для чего нужны макросы
> <ab> rider: у тебя получается не платформа, а размазня.
> <rider> ab: в смысле ?
> <ab> vsu: rider: что касается скорости, то с m-i-t (оригинальными) она сильно ниже, поскольку на каждый чих он запускает system
> <gvy> макросы для платформ -- идея здравая.  так у нас _вообще_ нет средств поддерживать специфические наборы хреновин, которые по случайному совпадению часто оказываются упакованными в один корпус
> <rider> ab: у меня будет лежать отдельный конфиг типа "m5wide.conf" - чем он тебе не нравится ?
> <ab> rider: и чем он отличается от /etc/modutils.d/m5wide.conf ?
> <mouse> ab:  :)
> <gvy> mouse, ! :
> <rider> ab: всем ;-) 
> <rider> ab: начиная с формата ;-)
> <rider> ab: и заканчивая тем, что описывать будет необходимо только специфические для платформы вещи
> <rider> ладно, давайте подумаем - для чего еще нужны макросы ;-)
> <ab> rider: Понимаешь, так ты теряешь информацию на уровне modules tools о платформе.
> <rider> ab: а она мне там не нужна !
> <vsu> ab: что - всё описание платформы влезет в modules.conf?
> <ab> vsu: вполне.
> <rider> vsu: одной платформы - может быть влезет.. не все конечно, но многие вещи
> <rider> vsu: а вот когда этих платформ двадцать ?
> <ab> vsu: просто постарайся подумать об этом без предубеждения.
> <ab> rider: и 20 влезут без проблем. Точнее, не будут использоваться, когда не надо.
> <vsu> ab: а `host_type` ты собираешься внутрь modutils вхачить? или бужешь по каждому поводу popen дёргать?
> <ab> vsu: я -- ничего не собираюсь. Ты бы видел, сколько там "вхачено"
> <vsu> ab: ага... похоже, именно поэтому его и решили переписать нафиг
> <ab> vsu: естественно. Но при этом выплеснули ребенка
> <ab> vsu: я был бы рад, если бы m-i-t делали две вещи:
> <ab>  - поддерживали бы старый формат модулей
> <ab>  - использовали бы макросы 
> <ab> нормальные макросы
> <ab> вот и все. 
> <vsu> ab: а написание "modutils 2.5.x" так и сдохло?
> <ab> vsu: оно выродилось в то, что сделал Rusty
> <rider> ab: не, мне эта идея не нравится ;-(
> <rider> ab: так пинайте автора mit, тем более патчи уже есть
> <ab> rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал
> <ab> rider: и я с ним согласен.
> <rider> ab: ты про то, что пускай все делают обертки сами ?
> <ab> он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны
> <ab> rider: да
> <ab> он сделал все, чтобы облегчить нам работу.
> <rider> ab: это все хорошо, но зачем нам тогда себе большой гемморой на тему отслеживания изменений в modutils и mit и синхронизации этих изменений ? Сколько времени уйдет у vsu при выходе каждой версии на просмотр diff'а и доработке нашей версии ?
> <ab> rider: я свое мнение высказал немного выше. Оно основано на анализе того, что есть сейчас.
> <ab> rider: Глебу получилось проще написать патч к modutils -- он меньше, чем портирование аналогичного кода в mit
> <ab> rider: возможно, наоборот (добавление нужного функционала в м-и-т) будет проще поддерживать, пусть и с большим объемом кода
> <UlfR> ab: не совсем так. Он меньше чем mit+федоровский_патч
> <ab> rider: факт в том, что код в modutils еще можно протолкнуть, поскольку обоснование можно построить на вполне твердой почве (2.2+2.4+2.6 в одном _уже_ использующемся продукте), а вот добавлять что либо в эксперимент под названием m-i-t не получится -- автор уже высказал свое мнение
> <ab> rider: в результате остается два пути: 
> <ab>  - развивать направление, начатое Глебом
> <ab>  - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils
> <ab> Второй вариант, при грамотной реализации, может быть принят остальными вендорами.
> <ab> vsu: суть в том, что текущий наш modutils решает тактические проблемы лучше федориного. Стратегически, лучше развивать второй вариант и стандартизировать его
> <rider> ab: я сильно в этом сомневаюсь... 
> <rider> ab: я про вендоров
> <gvy> а в lkml спрашивали?  или все здесь только?
> <ab> rider: я сомневаюсь меньше. На здравые идеи они реагируют нормально. Все, что уменьшает уровень лишнего бардака, принимается вполне быстро
> <rider> ab: кто будет заниматься этим вопросом ?
> <ab> gvy: нет. Это не совсем то место для обсуждения дистрибутивных проблем.
> <ab> rider: главная проблема сейчас в том, что _никто_ не сформулировал проблему. Все пытаются обходить реальность, порожденную предыдущими обходами
> <gvy> ab, какие ж они дистрибутивные?
> <ab> rider: не знаю.
> <gvy> они как минимум метадистрибутивные
> <gvy> и имеющее прямое отношение к
> <ab> gvy: дистрибутивные. Это для дистрибутива важно, чтобы у него единообразно все было
> <ab> gvy: я имею в виду дистрибутивные в противовес разработке ядра
> <rider> ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ?
> <ab> rider: нет, так не пойдет -- это глупо.
> <ab> rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами.
> <rider> ab: почему ? modutils из fedora вполне неплохой.
> <ab> rider: еще раз -- у него унифицированный макроязык для всех ядер?
> <rider> ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность
> <rider> ab: а зачем ?
> <rider> ab: естественно нет
> <ab> rider: я не вижу от него вопросов по патчам.
> <rider> ab: а они их никогда не задает. ;-)
> <ab> rider: тогда какой толк от федориных modutils.
> <rider> ab: ты же знаешь ldv ;-)
> <ab> rider: задает. Это ты его не знаешь.
> <rider> ab: они выполняют свою работу - грузят и выгружают модули ;-)
> <ab> не переводи серьезную тему в шутку
> <ab> rider: в вопросах по патчам "сомнениям" не место -- либо конкретные претензии, либо какие могут быть претензии? :-)
> <rider> ab: я не перевожу, я тебе вполне серьезно говорю - они выполняют свою работу с модулями. навешивать на них функциональность по детекту железа IMHO бесмысленно
> <vsu> rider: кстати, если действительно делать унифицированный язык, придётся менять и старую функциональность
> <rider> vsu: почему ?
> <ab> rider: при чем здесь "детект железа"?
> <vsu> rider: там две вещи: '-'/'_' и fnmatch
> <ab> rider: такое ощущение, что ты путаешь проблемы
> <rider> ab: я у тебя спрашивал уже - зачем нам нужен макроязык. Ты мне сказал для чего ?
> <vsu> rider: а иначе мы получим, что один и тот же файл с разными ядрами обрабатывается совершенно по-разному
> <ab> rider: то, что я тебе сказал сегодня -- идея Глеба, которую я просто озвучил. Он от нее уже отказался.
> <rider> ab: ясно
> <rider> ab: зачем еще нам нужен макроязык ?
> <rider> vsu: понятно
> <vsu> rider: именно из-за этого я выбросил вчерашний вариант (ну, не совсем выбросил... но почти)
> <ab> rider: для унификации настроек в рамках единой информационной среды (учить разные подходы при работе с разными ветвями ядер неэффективно).
> <vsu> rider: т.е. фактически это получается как раз что-то вроде "modutils 2.5.x" - с потенциальной несовместимостью
> <ab> rider: я пытаюсь уменьшить энтропию хотя бы в этом конкретном месте (работа с ядрами). Она (энтропия) настолько высока, что пользователи буквально захлебываются в ней. Мне не составляет проблемы настроить так, чтобы обе ветви ядер работали у меня на машине нормально, потому что я помню все и держу всю информацию в голове. Но это не дистрибутивный подход.
> <rider> ab: а зачем нам нужна эта унификация ?
> <rider> ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ?
> <rider> ab: она же сможет детектить версию ядра
> <rider> ab: т.е. - перенести макроязык в свое приложение, оторвав зависимость от modutils.
> <rider> ab: один черт придется что-то подобное ваять ;-(
> <UlfR> rider: тогда уж точно не нужны федорины патчи, имхо лучше тогда два пакета mu и mit_с_обвязкой разрулить при помощи rmp
> <UlfR> rpm т.е.
> <ab> rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож
> <ab> но добиться унификации 
> <rider> UlfR: можно и так.. федорины патчи хороши тем, что практически ничего не меняют
> <rider> ab: пользователь, по хорошему, вообще не должен знать ничего о mit и modutils ;-)
> <ab> rider: они меняют главное -- методику работы с ядрами для пользователя. Мне все равно, что внутри они "красивые" -- они вносят слишком много несовместимости
> <UlfR> rider: тогда толку от них если они ничего не меняют? :)
> <ab> rider: мы по-разному понимаем этот термин
> <rider> ab: какой из них ? ;-)
> <ab> rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д.
> <ab> rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д.
> <rider> ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот
> <rider> ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная.
> <rider> ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. 
> <ab> rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. 
> <ab> rider: потому что они не делают appliances :)
> <ab> rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале.
> <rider> ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях
> <ab> rider: просто подумай о аналогичной вещи -- мы были _первые_ кто подумал завести нормально дистрибутив нативно на arm.
> <rider> ab: какой дистрибутив ? Где он ?
> <ab> rider: Эх. Глупо.
> <ab> rider: у Интела на ftp :-)
> 
> [skip]
> 
> <rider> ab: ты не уходи от важного разговора.
> <rider> ab: вы займетесь modutils-ng ?
> <ab> rider: я уже все сказал по поводу modutils. 
> 
> [skip]
> 
> <rider> ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры)
> <ab> rider: прямо сейчас я урл дать не могу, на этой неделе будет Intel Developers Forum, где его будут демонстрировать
> <ab> rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам.
> 
> [skip]
> 
> <rider> ab: продолжим с IDE в ядер ? ;-)
> <rider> ab:  у меня был ряд вопросов по выносу IDE в модули.. 
> <ab> rider: поговори об этом с tren и ed через недельку.
> <rider> ab: недельку.. за недельку все может поменятся.. 
> <rider> ab: я не совсем понимаю как мы сделаем так, что бы пользователи могли харды переставлять из одной машины в другую.. ;-(
> <ab> rider: еще раз: поговори с теми, кто это делает, а не со мной. Они сейчас в отпуске.
> <rider> ab: дык ты же меня уговаривал на прошлой неделе вынести модули IDE из ядер... пропатчив все что детектит
> <ab> rider: потому что на прошлой неделе все были здесь и были готовы разговаривать на эту тему и делать эту работу. То, что ты отреагировал не на следующий день, как обещал, а через неделю -- увы, сейчас их нет.
> <rider> ab: у меня были другие дела ;-(
> <ab> теперь у нас другие :-(
> <ab> Мне сегодня нужно security updates собирать, а я с тобой здесь спорю. :-(
> <rider> UlfR: ладно, ab ушел от ответственности... ты то что скажешь про modutils, ты же патчил - знаешь сложность создания патчей.. да и зачем нужен макроязык тоже знаешь ;-)
> <rider> ab: а я уже собрал свой
> <ab> rider: что ты собрал?
> <gvy> rider, а с каких пор это в сизифе (и у тебя) стало котироваться "как у всех"?
> <gvy> это серьезный вопрос -- что главнее: "как у всех" или "правильно"?
> <gvy> rider, и начсет унификации -- "даешь унификацию макросов rpm!", а остальное уж как-то по мелочам утрясется
> <gvy> хотя это -- ключевая точка для девелоперов, которых меньше, но принцип (наблюдаемый) один
> <rider> ab: kernel-image-vs-smp
> <gvy> он даже был сформулирован ldv и занесен в фортунки
> <rider> gvy: тут немного о другом спор идет, хотя я тоже сторонник унификации макросов ;-)
> <rider> gvy: я имею в виду междистрибутивную унификацию
> <rider> gvy: я думаю, что мы когда-нить получим унификацию макросов.. хотя я могу и ошибаться.
> <gvy> rider, я прекрасно понимаю.  но в данном случае на 100% согласен с ab (вовсе не из позиции вида "все, что сказал rider -- чушь и его надо кунуть").
> <gvy> rider, попросту говоря -- если я что-то задвигал в апстримы, то как раз *на основании* обкатки в дистро
> <gvy> а тут -- критичный компонент
> <gvy> ab, rider -- но в lkml однозначно надо отсигналить.  всякую ^&*^&* обсуждать время им есть -- значит, на важный (вроде этого) вопрос тоже найдется
> <rider> gvy: я тоже согласен с ab, но ресурс на это выделять тяжело
> <gvy> rider, а если оно уже?
> <rider> gvy: судя по словам ldv оно еще далеко не уже
> <UlfR> rider: отрезать язык -- не добавить. я сразу отписывал, что варианта два. 1. патчить mu и вести их, 2. патчить mit и вести их. По сложности -- примерно одинаково. Про тактику и стратегию развития mu/mit Саша уже говорил. Ну конечно есть вариант вообще ничего не делать -- типа само утресётся.
> <lioka> gvy: да какая разница, что там думает lkml ? ненулевое количество пользователей alt-based distro консоли-то не видят. И это число, к прискорбию, будет увеличиваться.
> <gvy> lioka, это еще один довод, но они как раз ничего и не решают, так?
> <rider> UlfR: может быть третий вариант и выбрать, параллельно добивая авторов modutils и mit до унификации ?
> <rider> gvy: это не довод ;-(
> <gvy> rider, практика показывает, что утрясается обычно хуже, чем хотелось.  заметь, иначе бы нам тут и говорить было не о чем
> <lioka> решают те, кто саппортит. 
> <ab> rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. 
> <gvy> именно, в итоге
> <UlfR> ab: согласен
> <Grigory> Тут я уже видел apt для RH. Ждем? :-)
> <rider> gvy: давай я в тебя брошу новую версию mit и ты ее синхронизируешь с modutils... я просто не понимаю, зачем нам нужна _реально_ никому не нужная функциональность ?
> <lioka> а 'майнстримового' саппорта не бывает. period
> <gvy> rider, не надо в меня всяким бросаться
> <UlfR> rider: новую это какую?
> <gvy> rider, функциональность, про которую говорит ab -- нужна им и нужна мне.  чем плохо забивать на партнеров и их мнение -- лучше не будем вспоминать
> <ab> rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов.
> <rider> UlfR: module-init-tools-0.9.15-pre4.tar.bz2
> <UlfR> rider: это не новая ;)
> <rider> gvy: расскажи хоть ты мне - зачем тебе нужен макроязык ?
> <rider> UlfR: ;-)
> <gvy> rider, вспомни -- есть железки, которые "в розницу" (по компонентам, выуживая с pci) вроде и получается настроить -- да только из-за специфических ляпов _в сумме_ оно не работает
> <rider> UlfR: значит ту, которая не вышла ;-)
> <ab> rider: у меня последняя module-init-tools-3.0-pre9.tar.bz2
> <rider> gvy: ну и что, а макоязык тут при чем ?
> <rider> Упс, действительно уже есть 3.0-pre9
> <gvy> rider, сделай еще как-то.  я просто знаю, что ab и Grigory про это думают, а ты -- перегружен
> <gvy> rider, и в итоге часто допускаешь ошибки по таким точкам
> <rider> gvy: мы делаем, потому и перегружены
> <rider> gvy: ладно, бог с ним.. еще для чего нужен макроязык ?
> <gvy> rider, ну так делать-то надо то, чего нет или что есть недоделанное
> <gvy> минчанам надо -- пусть сделают, они-то на команду оглядываются
> <rider> gvy: мы делаем то, что считаем нужным.
> <rider> gvy: для наших клиентов
> <rider> gvy: ладно, зачем еще макроязык нужен ?
> <gvy> rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка)
> <rider> gvy: а зачем ?
> <gvy> в течение жизненного цикла 2.4
> <rider> gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ?
> <rider> gvy: еще зачем ?
> <gvy> для _единообразной_ поддержки.
> <gvy> rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине:
> <rider> gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ?
> <gvy> ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор;
> <gvy> они будут или _знать_ про то, как это было с 2.4 (=> опытные),
> <rider> gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться.
> <gvy> или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...)
> <gvy> так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет
> <rider> gvy: я не понял про YaST
> <gvy> сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4"
> <rider> gvy: ;-) 
> <gvy> rider, ну, "те, которые консоли не видят" (которым в общем пофиг, лишь бы работало)
> <gvy> понимаешь?
> <rider> gvy: ты посмотри сначала на разницу между modutils и mit ;-)
> <gvy> rider, я смотрел где-то при 2.5
> <ab> gvy: на самом деле, как это с 2.2, а то и раньше.
> <gvy> rider, и если ты не в курсе -- собирал m-i-t 
> <gvy> пакетил
> <rider> gvy: ;-)
> <gvy> и уже по N-му кругу думаю над этими граблями
> <gvy> потому что тогда тоже обнюхивал, как в cooker/rawhide/pld
> <gvy> понимаешь? ;-)
> <gvy> ab, отож. 
> <gvy> rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим
> <gvy> а эти идиоты полромали -- ну так это проблемы _их_ клиентов
> <rider> gvy: а нам думать уже все.. некогда ;-( Время ушло на раздумья. Подумали, хватит ... есть мантейнер - пускай принимает решение. А пакет на этой неделе должен быть в Sisyphus в рабочем виде 
> <gvy> rider, мож я ослеп, но то, что на people/ed/ -- у меня дома и в конторе работает
> <gvy> надо посмотреть, где мог костылями подпирать, пока алиасов не наделали...
> <rider> gvy: оно у меня тоже работает - иди докажи это ldv
> <ab> rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан.
> <ab> rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт.
> <gvy> rider, а где можно ознакомиться с претензиями ldv?  в devel-kernel@ было?
> <rider> ab: верю, сам на нем сижу.. иди доказывай это ldv. 
> <rider> ab: и пакета в Sisyphus тоже нет
> <gvy> rider, ну позови его сюда, что ли
> <gvy> :-)
> <rider> gvy: зови сам, мне это нахрен не нужно.... 
> * rider is away: Я занят
> <vsu> gvy: а багов в том патче есть... как, впрочем, и в чистом mit
> <ab> rider: я не собираюсь доказывать ничего тому, кто не хочет обсуждать. Это пагубная практика. Я только от тебя узнал, что он в этих патчах "сомневается".
> <gvy> rider, попробую по крайней мере написать всем почтой
> <gvy> vsu, баги всегда есть
> <ab> vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится.
> <gvy> точнее, я сейчас этот кусок перешлю в d-k@
> <ab> vsu: факт в том, что пакет работает, в том числе и со старыми ядрами. Проблем с ними не замечено.
> * lioka .oO (rider занят. мы -- так, шаро$#%мся)
> <gvy> lioka, да=-да, вот именно
> <-- rider has quit ("Вышел из XChat")
> * ab в расстроенных чувствах собирается домой. Через час.
> <UlfR> vsu: так млин, написали бы, где -- пофиксили бы...
> <vsu> UlfR: точнее, там кое-где изврат какой-то написан - работает правильно, но... а вот в get_kernel26_info заложена мина
> <UlfR> vsu: "там кое-где изврат какой-то написан" -- где можно, я подумаю как это сделать нормально. мина в чём?
> <vsu> UlfR: ldv особо понравился код if (obj_find_section(f, "__ksymtab_strings") != NULL) и то, что дальше :)
> <vsu> UlfR: а мина - n_module_stat = nmod = ret = 256; //временно
> <UlfR> vsu: мину разминировать? 
> <vsu> UlfR: я этот кусок переписал, но ещё не пробовал - сейчас кину
> --> rider (~rider@altlinux.balabanovo.ru) has joined #altlinux
> <gvy> ab, UlfR, vsu, rider -- никто от вышесказанного не отказывается?  дочищу и в d-k@
> <gvy> чтоб Диме было на что ссылаться
> <vsu> UlfR: поймал?
> <vsu> UlfR: да ладно, в mit ошибки ещё более классические :)
> <UlfR> vsu: ну с миной понятно, но чем так if (obj_find_sec... понравился? 




> _______________________________________________
> devel-kernel mailing list
> devel-kernel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel-kernel

Re: [d-kernel] q: modutils vs module-init-tools

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On Mon, Feb 09, 2004 at 08:24:52PM +0300, Anton Farygin wrote:
> > Вывод -- тащить modutils из Fedora.
> 1. Не тащить из Fedora, а собрать по аналогии.

Что собирать?  m-i-t для этого не предназначены by design.

> Ибо их решение мне понравилось (я про это уже говорил).
> Хотя это равнозначно по своей сути сборке двух отдельных
> пакетов, как оно изначально и задумывалось автором
> module-init-tools.

Я в свое время (~2.5.69? m-i-t-0.9.1[01]) попрыгал вокруг этого.
Вывод -- на localhost с некоторым количеством сдержанности и
парой хаков, которые никогда не примет майнтейнер modutils,
пользовать можно.  А как в дистрибутив -- не представляю.

Собственно, на этом и закончились тогда _мои_ потуги собрать 2.5
для Daedalus.

> Для долговременной и успешной поддержки некоего симбиоза из ужа
> с ежом нам на работу срочно требуется десяток профессиональных
> генетиков со стажем работы.

Уже сделали.  Ты хочешь ужа с дикобразом и геморроем суппорту?

> Хорошо. Давайте тогда соберем два отдельных пакета, как сделано
> в Debian и не будем тратить время и силы на изобретение
> велосипеда.

Они _уже_ потрачены.  И в данном случае это далеко не настолько
велосипед, сколько оправданное экономически решение, сохраняющие
инвестиции времени, произведенные системными администраторами
клиентов за время жизни linux-2.2/2.4.

В общем, все уже сказано.  Лучшее, что можно добавить -- это
SWOT-анализ после рассказа ldv и vsu о _технических_ проблемах с
принятием ed/modutils в Sisyphus.

PS: SWOT -- это "Strengths, Weaknesses, Opportunities, Threats",
бишь чем какие варианты хороши/плохи.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Q: modutils vs module-init-tools

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2047 bytes --]

On Mon, Feb 09, 2004 at 07:19:01PM +0200, Michael Shigorin wrote:
> 	Здравствуйте.
> Сегодня на #altlinux имели место очередные прения.

На сегодняшний день существуют 3 принципиально разных подхода к проблеме:

1. mu+mit под одной тонкой крышей (как у Федоры, SuSE, Debian).
Это самый лёгкий в реализации и наиболее неудобный в эксплуатации вариант,
который производит впечатление временного.  Основное неудобство заключено
в существенных различиях конфигурирования для mu и mit.

2. mu с добавлением функционала из mit (как в /pub/people/ed).
Этот вариант призван существенно облегчить миграцию на 2.6 для сисадминов
благодаря полной совместимости с чистым mu.  Требует постоянных затрат на
поддержание актуального функционала из mit.  Ввиду того, что в mu и так
наблюдается переизбыток функционала, шансов на то, что этот подход будет
поддержан другими вендорами, мало, т.е. все затраты на поддержку лягут на
ALT.

3. mit с добавлением функционала из mu (реализации нет).
Этот вариант призван решить обе задачи, т.е. и облегчить миграцию с 2.4, и
избавиться от лишнего функционала толстого mu.  Требует постоянных затрат
на поддержание актуального функционала из mit.  Шансов на то, что этот
подход будет поддержан другими вендорами, по-моему, больше, но только в
случае, если будет предложена уже работающая реализация.  Есть опасность
того, что первая реализация будет плохо работать со всеми ядрами.

Вариант 1. мне не нравится, делать времянку на несколько лет я бы не хотел.

Вариант 2. меня устраивает больше, но текущая реализация
(modutils-2.4.25-alt16) меня не устраивает: вносимые изменения содержат
явные ляпы (которые мы обсудили 6-го февраля с vsu@), и мне не очевидно,
что они (изменения) не портят поддержку 2.4.  Думаю, что эту реализацию
можно довести до ума.  2vsu: когда?

Вариант 3. этот вариант теоретически лучше всех, но отсутствие рабочей
реализации сводит все его преимущества на нет.

2ab: Это ведь серьёзная тема, выбор не очевиден, наших ресурсов не хватает,
может, стоит обсудить в xvendor@?  Возьмёшься?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Q: modutils vs module-init-tools

[Alexander Bokovoy]

On Tue, Feb 10, 2004 at 03:51:00PM +0300, Dmitry V. Levin wrote:
> On Mon, Feb 09, 2004 at 07:19:01PM +0200, Michael Shigorin wrote:
> > 	Здравствуйте.
> > Сегодня на #altlinux имели место очередные прения.
> 
> На сегодняшний день существуют 3 принципиально разных подхода к проблеме:
> 
> 1. mu+mit под одной тонкой крышей (как у Федоры, SuSE, Debian).
> Это самый лёгкий в реализации и наиболее неудобный в эксплуатации вариант,
> который производит впечатление временного.  Основное неудобство заключено
> в существенных различиях конфигурирования для mu и mit.
> 
> 2. mu с добавлением функционала из mit (как в /pub/people/ed).
> Этот вариант призван существенно облегчить миграцию на 2.6 для сисадминов
> благодаря полной совместимости с чистым mu.  Требует постоянных затрат на
> поддержание актуального функционала из mit.  Ввиду того, что в mu и так
> наблюдается переизбыток функционала, шансов на то, что этот подход будет
> поддержан другими вендорами, мало, т.е. все затраты на поддержку лягут на
> ALT.
> 
> 3. mit с добавлением функционала из mu (реализации нет).
> Этот вариант призван решить обе задачи, т.е. и облегчить миграцию с 2.4, и
> избавиться от лишнего функционала толстого mu.  Требует постоянных затрат
> на поддержание актуального функционала из mit.  Шансов на то, что этот
> подход будет поддержан другими вендорами, по-моему, больше, но только в
> случае, если будет предложена уже работающая реализация.  Есть опасность
> того, что первая реализация будет плохо работать со всеми ядрами.
> 
> Вариант 1. мне не нравится, делать времянку на несколько лет я бы не хотел.
> 
> Вариант 2. меня устраивает больше, но текущая реализация
> (modutils-2.4.25-alt16) меня не устраивает: вносимые изменения содержат
> явные ляпы (которые мы обсудили 6-го февраля с vsu@), и мне не очевидно,
> что они (изменения) не портят поддержку 2.4.  Думаю, что эту реализацию
> можно довести до ума.  2vsu: когда?
Как я вчера уже говорил, этот вариант стоит рассматривать как тактический
ход.

> Вариант 3. этот вариант теоретически лучше всех, но отсутствие рабочей
> реализации сводит все его преимущества на нет.
Это стратегическое направление, с моей точки зрения.
 
> 2ab: Это ведь серьёзная тема, выбор не очевиден, наших ресурсов не хватает,
> может, стоит обсудить в xvendor@?  Возьмёшься?
Возьмусь. Потребуется около недели, наверное: надо еще понять, куда в SuSE
ветры дуют после объединения (Mantel вдруг перестал собирать ядра).

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

Re: [d-kernel] Q: modutils vs module-init-tools

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]

On Tue, Feb 10, 2004 at 03:51:00PM +0300, Dmitry V. Levin wrote:
> На сегодняшний день существуют 3 принципиально разных подхода к проблеме:
> 
> 1. mu+mit под одной тонкой крышей (как у Федоры, SuSE, Debian).
> Это самый лёгкий в реализации и наиболее неудобный в эксплуатации вариант,
> который производит впечатление временного.  Основное неудобство заключено
> в существенных различиях конфигурирования для mu и mit.
> 
> 2. mu с добавлением функционала из mit (как в /pub/people/ed).
> Этот вариант призван существенно облегчить миграцию на 2.6 для сисадминов
> благодаря полной совместимости с чистым mu.  Требует постоянных затрат на
> поддержание актуального функционала из mit.  Ввиду того, что в mu и так
> наблюдается переизбыток функционала, шансов на то, что этот подход будет
> поддержан другими вендорами, мало, т.е. все затраты на поддержку лягут на
> ALT.
> 
> 3. mit с добавлением функционала из mu (реализации нет).
> Этот вариант призван решить обе задачи, т.е. и облегчить миграцию с 2.4, и
> избавиться от лишнего функционала толстого mu.  Требует постоянных затрат
> на поддержание актуального функционала из mit.  Шансов на то, что этот
> подход будет поддержан другими вендорами, по-моему, больше, но только в
> случае, если будет предложена уже работающая реализация.  Есть опасность
> того, что первая реализация будет плохо работать со всеми ядрами.
> 
> Вариант 1. мне не нравится, делать времянку на несколько лет я бы не хотел.
> 
> Вариант 2. меня устраивает больше, но текущая реализация
> (modutils-2.4.25-alt16) меня не устраивает: вносимые изменения содержат
> явные ляпы (которые мы обсудили 6-го февраля с vsu@), и мне не очевидно,
> что они (изменения) не портят поддержку 2.4.  Думаю, что эту реализацию
> можно довести до ума.  2vsu: когда?

Написал уже второй вариант, который в конечном итоге мне опять не
понравился :)

В 2.6 есть два изменения в обработке имён модулей:

1. В команде alias в исходном имени могут использоваться шаблоны в
стиле shell.

2. В имени модуля в ядре все символы '-' заменяются на '_', при этом
в именах файлов может встречаться и то, и другое.  В mit это
обрабатывается путём замены всех '-' на '_' во всех случаях (в
именах из командной строки и из файла конфигурации).

По поводу п.1, вероятно, особых проблем от использования нового
варианта и для 2.6, и для 2.4 не будет.  Для п.2 я вижу несколько
вариантов решения:

а) Менять алгоритм сравнения имён модулей в зависимости от версии
ядра.  Сохраняется максимальная совместимость с 2.4, но различие в
обработке одного и того же файла конфигурации с разными версиями
ядра выглядит довольно странно.

б) Считать '-' и '_' в именах модулей эквивалентными вне зависимости
от версии ядра.  В этом случае меняется работа и для 2.4 (хотя
модули с именами, различающимися только этими символами, мне не
попадались), зато достигается единообразие в обработке файлов
конфигурации.

Промежуточные варианты (считать '-' и '_' эквивалентными только в
отдельных командах) вряд ли достойны рассмотрения (скорее всего,
результатом реализации подобных вариантов будут багрепорты по поводу
команд, в которых эта эквивалентность не обрабатывается).  Кстати, в
упомянутом modutils-2.4.25-alt16, похоже, наблюдается именно такая
ситуация с options - может получиться так, что модуль найдётся, а
строка options для него не будет обработана.

На самом деле эту проблему придётся решать вне зависимости от того,
что брать в качестве базы - mit или mu.  Я пока что склоняюсь ко
второму варианту (хотя в любом случае патч для действительно
правильной работы mu с такими именами получается большой).

> Вариант 3. этот вариант теоретически лучше всех, но отсутствие рабочей
> реализации сводит все его преимущества на нет.
> 
> 2ab: Это ведь серьёзная тема, выбор не очевиден, наших ресурсов не хватает,
> может, стоит обсудить в xvendor@?  Возьмёшься?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Q: modutils vs module-init-tools

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Tue, Feb 10, 2004 at 05:34:04PM +0300, Sergey Vlasov wrote:
[...]
> Написал уже второй вариант, который в конечном итоге мне опять не
> понравился :)
> 
> В 2.6 есть два изменения в обработке имён модулей:
> 
> 1. В команде alias в исходном имени могут использоваться шаблоны в
> стиле shell.
> 
> 2. В имени модуля в ядре все символы '-' заменяются на '_', при этом
> в именах файлов может встречаться и то, и другое.  В mit это
> обрабатывается путём замены всех '-' на '_' во всех случаях (в
> именах из командной строки и из файла конфигурации).
> 
> По поводу п.1, вероятно, особых проблем от использования нового
> варианта и для 2.6, и для 2.4 не будет.

Мне тоже так кажется.

> Для п.2 я вижу несколько вариантов решения:
[...]
> б) Считать '-' и '_' в именах модулей эквивалентными вне зависимости
> от версии ядра.  В этом случае меняется работа и для 2.4 (хотя
> модули с именами, различающимися только этими символами, мне не
> попадались), зато достигается единообразие в обработке файлов
> конфигурации.
[...]
> На самом деле эту проблему придётся решать вне зависимости от того,
> что брать в качестве базы - mit или mu.  Я пока что склоняюсь ко
> второму варианту (хотя в любом случае патч для действительно
> правильной работы mu с такими именами получается большой).

Согласен.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]