From: Anton Farygin <rider@altlinux.com> To: devel-kernel@altlinux.ru Subject: Re: [d-kernel] q: modutils vs module-init-tools Date: Mon, 9 Feb 2004 20:24:52 +0300 Message-ID: <20040209172452.GK15073@master.altlinux.ru> (raw) In-Reply-To: <20040209171901.GS16611@osdn.org.ua> 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
next prev parent reply other threads:[~2004-02-09 17:24 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-09 17:19 Michael Shigorin 2004-02-09 17:24 ` Anton Farygin [this message] 2004-02-09 18:08 ` Michael Shigorin 2004-02-10 12:51 ` [d-kernel] Q: " Dmitry V. Levin 2004-02-10 13:39 ` Alexander Bokovoy 2004-02-10 14:34 ` Sergey Vlasov 2004-02-10 14:49 ` Dmitry V. Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20040209172452.GK15073@master.altlinux.ru \ --to=rider@altlinux.com \ --cc=devel-kernel@altlinux.ru \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux kernel packages development This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel-kernel/0 devel-kernel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel-kernel devel-kernel/ http://lore.altlinux.org/devel-kernel \ devel-kernel@altlinux.org devel-kernel@altlinux.ru devel-kernel@altlinux.com public-inbox-index devel-kernel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git