From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 9 Feb 2004 19:19:01 +0200 From: Michael Shigorin To: devel-kernel@altlinux.ru Message-ID: <20040209171901.GS16611@osdn.org.ua> Mail-Followup-To: devel-kernel@altlinux.ru Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pN9MePJoZbRKbUk1" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [d-kernel] q: modutils vs module-init-tools X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 17:19:08 -0000 Archived-At: List-Archive: List-Post: --pN9MePJoZbRKbUk1 Content-Type: multipart/mixed; boundary="aznLbwQ42o7LEaqN" Content-Disposition: inline Content-Transfer-Encoding: 8bit --aznLbwQ42o7LEaqN Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit Здравствуйте. Сегодня на #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@. Смотреть на них в таком системообразующем вопросе -- глупо и смешно. А отказываться от проверенного варианта в пользу концепт-кара с "простым" (нафигнужным) патчем -- безумие. --- vsu: надобы свести воедино modutils. Я таки добавил *.inputmap UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils vsu: тогда какие предложения? UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools vsu: Мы теряем главное -- макроязык vsu: он (м-и-т) вообще покоцанный, это не показатель. vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг" ab: просто у меня возникает ощущение, что мы делаем что-то не то.. ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :( ab: очень не хотелось бы делать fork modutils ;-( rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т ab: а написание "modutils 2.5.x" так и сдохло? vsu: оно выродилось в то, что сделал Rusty ab: так пинайте автора mit, тем более патчи уже есть rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал rider: и я с ним согласен. ab: ты про то, что пускай все делают обертки сами ? он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны rider: в результате остается два пути: - развивать направление, начатое Глебом - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils Второй вариант, при грамотной реализации, может быть принят остальными вендорами. ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ? rider: нет, так не пойдет -- это глупо. rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами. ab: почему ? modutils из fedora вполне неплохой. rider: еще раз -- у него унифицированный макроязык для всех ядер? ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность rider: я не вижу от него вопросов по патчам. ab: а зачем нам нужна эта унификация ? ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ? rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож но добиться унификации [skip] rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д. rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д. ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная. ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. rider: потому что они не делают appliances :) rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале. ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры) rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам. решают те, кто саппортит. rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. именно, в итоге ab: согласен Тут я уже видел apt для RH. Ждем? :-) а 'майнстримового' саппорта не бывает. period rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов. gvy: ладно, зачем еще макроязык нужен ? rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка) в течение жизненного цикла 2.4 gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ? для _единообразной_ поддержки. rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине: gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ? ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор; они будут или _знать_ про то, как это было с 2.4 (=> опытные), gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться. или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...) так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет gvy: я не понял про YaST сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4" [skip] rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим а эти идиоты полромали -- ну так это проблемы _их_ клиентов rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан. rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт. rider, а где можно ознакомиться с претензиями ldv? в devel-kernel@ было? ab: верю, сам на нем сижу.. иди доказывай это ldv. gvy: а багов в том патче есть... как, впрочем, и в чистом mit vsu, баги всегда есть vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/ --aznLbwQ42o7LEaqN Content-Type: text/plain; charset=koi8-r Content-Disposition: attachment; filename="altlinux-irc-modutils-20040209.log" Content-Transfer-Encoding: 8bit --> vsu (~vsu@mivlgu.ru) has joined #altlinux $@#$%#$#%@#$%#$#$@ detectloader!!! vsu: UlfR: vsu: надобы свести воедино modutils. Я таки добавил *.inputmap UlfR: вообще есть мнение, что добавлять всё-таки надо не так vsu: ? UlfR: дело в том, что в таком варианте может быть слишком много возни при обновлении как module-init-tools, так и modutils vsu: тогда какие предложения? UlfR: использовать кусок патча из fedora - depmod можно просто вызывать из module-init-tools UlfR: insmod в принципе тоже UlfR: т.е. фактически сильно патчить нужно только modprobe vsu: зачем? vsu: Мы теряем главное -- макроязык ab: так макроязык как раз весь в modprobe vsu: и в depmod ab: pcimapfile=...? так он и для 2.4, похоже, уже сломан vsu: не только. Там больше. ab: что именно? vsu: всё что *file vsu: generic_stringfile, depfile, ..., prune vsu: он линкуется с config_read, соответственно, читает конфигурационный файл и парсит все UlfR: ну и кому оно нужно? это уже сейчас сломано, и никто не заметил vsu: заметили. Это отлично видно на новом hotplug --> rider_ (~rider@altlinux.balabanovo.ru) has joined #altlinux ab: а что, новый hotplug хочет засовывать эти файлы куда-то в другое место? rider_, ! :) vsu: суть не в "засовывать", а в "использовать". Новый хотплаг использует много. vsu: в частности, умеет использовать input hi ppl --- rider_ is now known as rider ab: т.е. ему нужен /lib/modules/`uname -r`/modules.input (или как там он точно называется)? vsu: inputmap ab: замечания по Max'у ? ab: ну и каким боком здесь макроязык? depmod и без него этот файл сделает ab: ааа.. да, есть такое дело.. сейчас перешлю vsu: при том, что depmod не будет работать, если не сможет распарсить основной конфиг. vsu: вообще не будет работать. ab: depmod из module-init-tools вообще в конфиг не смотрит vsu: он (м-и-т) вообще покоцанный, это не показатель. vsu: в м-и-т основная проблема в его мотто: "Я маленький такой, мне все остальное пофиг" ab: вообще реально все эти path и *file из modules.conf кому-нибудь нужны? vsu: да vsu: в частности, для сосуществования межархитектурных карт (32/64) ab: и куда они в подобном случае показывают? ab: ушел vsu: обычно они показывают в значения по умолчанию, но при помощи MODPATH их можно переопределить ab: а вы не писали автору module-init-tools и автору modutils письмо с патчем, объединяющим функциональность ? rider: UlfR что-то писал UlfR: а ответ пришел ? rider: он в отпуске был ab: просто у меня возникает ощущение, что мы делаем что-то не то.. на неделе отпишу ещё раз ab: чем больше мы будем вот так всё патчить, тем глубже мы будем вязнуть в этих патчах :( UlfR: отпиши плз vsu: именно ;-( * mouse is back (gone 93:22:07) rider: vsu UlfR: ab: hi mouse: mouse: привет ! ты куда пропал ? mouse: vsu: объясни мне, _зачем_ идти следом за Расти в его упрощениях, если при этом теряется основной функционал, а он сам заявляет: "я специально делаю проще, чтобы другие могли сделать как надо для них" ab: так может быть и сделать так как надо нам, но не патчами, а оберткой над module-init-tools ? ab: покажи, кому реально нужен этот функционал именно в depmod ab: по поводу modprobe я как раз не спорю ab: и то - *path там и для 2.4 уже сколько времени сломаны, и никто не замечает. значит, не нужны UlfR: ed'а нет сегодня ? rider: нет он в отпуске на недельку UlfR: ты не в курсе, зачем он SysRq отключал в своих сборках 2.6 ? rider: не в курсе. Он наверное его просто не включал :) UlfR: ;-) * rider готовит среду для сборки 2.6.2 в Sisyphus vsu: они там не сломаны, а забиты намертво и изменяются посредством MODPATH rider: у нас уже давно все готово ab: не.. пока это не в Sisyphus - это не готово.. а я говорю про наш ядерный CVS ;-) ab: а вот параметра для перекрытия версии ядра там всё равно не хватает ab: очень не хотелось бы делать fork modutils ;-( vsu: можно обойтись в MODPATH прямым указанием. rider: на обратном пути (через м-и-т) у тебя неумолимо получается форк м-и-т ab: почему ? rider: я уже объяснял почему. Посмотри выше ab: нет, они именно сломаны ab: в /etc/modutils.d/* они работают ab: как тогда живет RH, просто объединяя в один бинарник mit и modutils, но при этом не расширяя функциональность mit ? vsu: ты говоришь про переназначение в конфигурационном файле, а я про переменные среды. ab: а вот в modules.conf уже нет rider: у RH еще нет дистрибутива на 2.6. И видимо, они не сильно используют макросы ab: так вопрос был "зачем depmod конфигурационный файл?" ab: на самом деле макросы практически никто не использует ;-( ab: и мы в том числе rider: дело в том, что даже смотря в код RH AS 2.1 я не обнаружил нормального использования modutils. ab: дык его нигде нет ab: а version override всё-таки нужен - иначе есть вероятность, что mkinitrd будет работать неправильно rider: и что ты предлагаешь? Выкинуть все нафиг? ab: как раз при активном использовании макросов vsu: я согласен, что последнее нужно. Вопрос в том, _зачем_ ради этого все переделывать в рамках mit? ab: почему всё? vsu: ну можно чуть подправить depmod, можно конечно version override добавить ab: я думаю ;-) vsu: или я не понимаю, что вы с Антоном говорите, или вы говорите что-то неформализованное ab: например, какая разница между реализациями insmod? обе тупые ab: вот и предлагается вместо толстых патчей просто цеплять insmod из mit vsu: так ты так и говори сразу, а не "вообще есть мнение, что добавлять всё-таки надо не так" и ссылаться на совсем иное ab: нам надо по хорошему сделать максимально простой поддержку своих modutils и mit объединенных.. rider: вообще Глеб сейчас родил идею: "Для чего нам нужны макросы" ab: что бы не тратить время на портирование патчей ab: и ? "Для того, чтобы на уровне modules tools разбирать конфигурации машин автоматически и описывать их только вхождениями в /etc/modutils.d/" Так, для каждого типа, скажем, Максов, будет свой отдельный файл конфигурации -- набор макросов. И все, остальное автоматом поднимется далее вся эта толпа внутри файлов обвязана if `host_type` == m5wide .... ab: ой ужас ab: остановись !!! ab: и всё это разбирается в runtime???? ab: ещё include `host_type` напиши :) :-) vsu: rider: а чем не нравится-то? :) UlfR: всем !!! Начиная с того, что мне придется поддерживать плафтормы, и заканчивая тем - что все равно придется делать детект железа. vsu: по поводу разборок -- скорость загрузки модулей не так критична на самом деле. ab: ты не прав ;-) rider: ты все равно поддерживаешь платформы. ab: вот это не критично и то не критично.. а в итоге все тормозит.. ab: а зачем делать двойную работу, добавляя конфиги для платформ и одновременно разрабатывая средства для детекта железа ? rider: мне не нравится генератор конфигурации типа configure, потому что он описывает на самом деле не платформу, а некоторую среднюю температуру по больнице. ab: а что, куча if это опишет лучше? ab: конфиги для платформ мы можем вынести в генератор конфигурации, который будет детектить платформу и тюнить конфиг под нее.. это по моему просто ;-) vsu: смотри на это как на case :-) ab: вы что там пили сегодня ? ;-) ab: или куча if в modules.conf лучше, чем такая же куча в something.sh/.pl/.rb/...? vsu: rider: ну да согласен, пример не очень :) UlfR: ;-) rider: квас нормальный :-) UlfR: в итоге пришли к тому, что никто не знает для чего нужны платформы ;-) rider: что пил UlfR -- не знаю :-) ab: хорошо хоть не лимонник ;-) тьфу ты. :) заговорился rider, ты того, полегче ;-) в итоге пришли к тому, что никто не знает для чего нужны макросы rider: у тебя получается не платформа, а размазня. ab: в смысле ? vsu: rider: что касается скорости, то с m-i-t (оригинальными) она сильно ниже, поскольку на каждый чих он запускает system макросы для платформ -- идея здравая. так у нас _вообще_ нет средств поддерживать специфические наборы хреновин, которые по случайному совпадению часто оказываются упакованными в один корпус ab: у меня будет лежать отдельный конфиг типа "m5wide.conf" - чем он тебе не нравится ? rider: и чем он отличается от /etc/modutils.d/m5wide.conf ? ab: :) mouse, ! : ab: всем ;-) ab: начиная с формата ;-) ab: и заканчивая тем, что описывать будет необходимо только специфические для платформы вещи ладно, давайте подумаем - для чего еще нужны макросы ;-) rider: Понимаешь, так ты теряешь информацию на уровне modules tools о платформе. ab: а она мне там не нужна ! ab: что - всё описание платформы влезет в modules.conf? vsu: вполне. vsu: одной платформы - может быть влезет.. не все конечно, но многие вещи vsu: а вот когда этих платформ двадцать ? vsu: просто постарайся подумать об этом без предубеждения. rider: и 20 влезут без проблем. Точнее, не будут использоваться, когда не надо. ab: а `host_type` ты собираешься внутрь modutils вхачить? или бужешь по каждому поводу popen дёргать? vsu: я -- ничего не собираюсь. Ты бы видел, сколько там "вхачено" ab: ага... похоже, именно поэтому его и решили переписать нафиг vsu: естественно. Но при этом выплеснули ребенка vsu: я был бы рад, если бы m-i-t делали две вещи: - поддерживали бы старый формат модулей - использовали бы макросы нормальные макросы вот и все. ab: а написание "modutils 2.5.x" так и сдохло? vsu: оно выродилось в то, что сделал Rusty ab: не, мне эта идея не нравится ;-( ab: так пинайте автора mit, тем более патчи уже есть rider: еще раз: его пинать не надо. Он уже все в последнем абзаце нового modules.conf(5) все сказал rider: и я с ним согласен. ab: ты про то, что пускай все делают обертки сами ? он не занимается разработкой дистрибутивов, ему наши задачи и проблемы не интересны rider: да он сделал все, чтобы облегчить нам работу. ab: это все хорошо, но зачем нам тогда себе большой гемморой на тему отслеживания изменений в modutils и mit и синхронизации этих изменений ? Сколько времени уйдет у vsu при выходе каждой версии на просмотр diff'а и доработке нашей версии ? rider: я свое мнение высказал немного выше. Оно основано на анализе того, что есть сейчас. rider: Глебу получилось проще написать патч к modutils -- он меньше, чем портирование аналогичного кода в mit rider: возможно, наоборот (добавление нужного функционала в м-и-т) будет проще поддерживать, пусть и с большим объемом кода ab: не совсем так. Он меньше чем mit+федоровский_патч rider: факт в том, что код в modutils еще можно протолкнуть, поскольку обоснование можно построить на вполне твердой почве (2.2+2.4+2.6 в одном _уже_ использующемся продукте), а вот добавлять что либо в эксперимент под названием m-i-t не получится -- автор уже высказал свое мнение rider: в результате остается два пути: - развивать направление, начатое Глебом - сделать новые утилиты на базе m-i-t с втягиванием функционала из modutils Второй вариант, при грамотной реализации, может быть принят остальными вендорами. vsu: суть в том, что текущий наш modutils решает тактические проблемы лучше федориного. Стратегически, лучше развивать второй вариант и стандартизировать его ab: я сильно в этом сомневаюсь... ab: я про вендоров а в lkml спрашивали? или все здесь только? rider: я сомневаюсь меньше. На здравые идеи они реагируют нормально. Все, что уменьшает уровень лишнего бардака, принимается вполне быстро ab: кто будет заниматься этим вопросом ? gvy: нет. Это не совсем то место для обсуждения дистрибутивных проблем. rider: главная проблема сейчас в том, что _никто_ не сформулировал проблему. Все пытаются обходить реальность, порожденную предыдущими обходами ab, какие ж они дистрибутивные? rider: не знаю. они как минимум метадистрибутивные и имеющее прямое отношение к gvy: дистрибутивные. Это для дистрибутива важно, чтобы у него единообразно все было gvy: я имею в виду дистрибутивные в противовес разработке ядра ab: давайте сделаем так: в Sisyphus сейчас пустим mit+modutils аля Fedora, ну и параллельно Глеб или кто-то из ваших ребят начнут продавливать автора modutils на включение патчей ? rider: нет, так не пойдет -- это глупо. rider: Я предлагаю пустить в Сизиф текущие наши modutils, а самим заняться разработкой нормального решения и обсуждением с остальными вендорами. ab: почему ? modutils из fedora вполне неплохой. rider: еще раз -- у него унифицированный макроязык для всех ядер? ab: ldv не пропускает ваши текущие modutils - слишком много вопросов у него по патчам. Т.е. - он сомневается что этот патч не ломает существующую функциональность ab: а зачем ? ab: естественно нет rider: я не вижу от него вопросов по патчам. ab: а они их никогда не задает. ;-) rider: тогда какой толк от федориных modutils. ab: ты же знаешь ldv ;-) rider: задает. Это ты его не знаешь. ab: они выполняют свою работу - грузят и выгружают модули ;-) не переводи серьезную тему в шутку rider: в вопросах по патчам "сомнениям" не место -- либо конкретные претензии, либо какие могут быть претензии? :-) ab: я не перевожу, я тебе вполне серьезно говорю - они выполняют свою работу с модулями. навешивать на них функциональность по детекту железа IMHO бесмысленно rider: кстати, если действительно делать унифицированный язык, придётся менять и старую функциональность vsu: почему ? rider: при чем здесь "детект железа"? rider: там две вещи: '-'/'_' и fnmatch rider: такое ощущение, что ты путаешь проблемы ab: я у тебя спрашивал уже - зачем нам нужен макроязык. Ты мне сказал для чего ? rider: а иначе мы получим, что один и тот же файл с разными ядрами обрабатывается совершенно по-разному rider: то, что я тебе сказал сегодня -- идея Глеба, которую я просто озвучил. Он от нее уже отказался. ab: ясно ab: зачем еще нам нужен макроязык ? vsu: понятно rider: именно из-за этого я выбросил вчерашний вариант (ну, не совсем выбросил... но почти) rider: для унификации настроек в рамках единой информационной среды (учить разные подходы при работе с разными ветвями ядер неэффективно). rider: т.е. фактически это получается как раз что-то вроде "modutils 2.5.x" - с потенциальной несовместимостью rider: я пытаюсь уменьшить энтропию хотя бы в этом конкретном месте (работа с ядрами). Она (энтропия) настолько высока, что пользователи буквально захлебываются в ней. Мне не составляет проблемы настроить так, чтобы обе ветви ядер работали у меня на машине нормально, потому что я помню все и держу всю информацию в голове. Но это не дистрибутивный подход. ab: а зачем нам нужна эта унификация ? ab: все равно мы попадаем на то, что у нас модули по другому называются.. не проще ли сделать обвязку над insmod/modprobe/rmmod, которая будет делать все так как нам надо ? ab: она же сможет детектить версию ядра ab: т.е. - перенести макроязык в свое приложение, оторвав зависимость от modutils. ab: один черт придется что-то подобное ваять ;-( rider: тогда уж точно не нужны федорины патчи, имхо лучше тогда два пакета mu и mit_с_обвязкой разрулить при помощи rmp rpm т.е. rider: Ты постарайся оторваться от деталей нижнего уровня -- имен модулей, директорий и т.д. Подумай о другом: для пользователя разница между настройками двух веток ядер не оправдывается тем, что "разработчики в очередной раз усовершенствовали внутренности ядра". Пользователю плевать на это и я согласен с этим -- как бы не меняли реализацию, внешняя оболочка от этого страдать не должна. Более того, наш опыт показывает, что и не страдает -- мож но добиться унификации UlfR: можно и так.. федорины патчи хороши тем, что практически ничего не меняют ab: пользователь, по хорошему, вообще не должен знать ничего о mit и modutils ;-) rider: они меняют главное -- методику работы с ядрами для пользователя. Мне все равно, что внутри они "красивые" -- они вносят слишком много несовместимости rider: тогда толку от них если они ничего не меняют? :) rider: мы по-разному понимаем этот термин ab: какой из них ? ;-) rider: я не говорю о lusers. Я говорю о пользователях, которыми являемся мы сами, администраторы крупных систем и т.д. rider: мне в данном случае интересен унифицированный подход для них, а не для тех, кто ничего читать не хочет, ничего не знает, и т.д. ab: аа.. понятно. для них все равно придется переучиваться на mit, ибо если мы сделаем не так как RH, SuSE и остальные - грабли будут у тех пользователей, кто переходит с SuSE на 2.6 на alt на 2.6 и наоборот ab: т.е. - унификация IMHO должна быть междистрибутивная, а не внутридистрибутивная. ab: я не понимаю, почему объединение функциональности не было сделано в SuSE, MDK или RH. rider: это следующий этап. Если наш подход себя оправдает (в чем я уверен), то его возьмут и остальные. rider: потому что они не делают appliances :) rider: на самом деле, я тебе при личной встрече могу рассказать почему. Не хочется говорить о их состоянии в дистрибутивных методиках на канале. ab: так давай сначала сделаем отдельную ветку (modutils-ng), сделаем для них сайт, добъемся выкладывания modutils-ng на ftp.kernel.org, а потом уже будем экспериментировать на наших пользователях rider: просто подумай о аналогичной вещи -- мы были _первые_ кто подумал завести нормально дистрибутив нативно на arm. ab: какой дистрибутив ? Где он ? rider: Эх. Глупо. rider: у Интела на ftp :-) [skip] ab: ты не уходи от важного разговора. ab: вы займетесь modutils-ng ? rider: я уже все сказал по поводу modutils. [skip] ab: из того что ты сказал ясно одно - мы хотим как лучше, как круче... но не так как у всех. При этом зачем нужна эта крутизна - мне так и не понятно .. аргументы типа "так будет лучше пользователям" я не воспринимаю, ибо стандартом станет mit и все равно всем админам придется переучиваться (читай забыть старые параметры) rider: прямо сейчас я урл дать не могу, на этой неделе будет Intel Developers Forum, где его будут демонстрировать rider: речь не идет о "как круче". Впрочем, я уже все сказал на эту тему -- не хочу ходить по кругам. [skip] ab: продолжим с IDE в ядер ? ;-) ab: у меня был ряд вопросов по выносу IDE в модули.. rider: поговори об этом с tren и ed через недельку. ab: недельку.. за недельку все может поменятся.. ab: я не совсем понимаю как мы сделаем так, что бы пользователи могли харды переставлять из одной машины в другую.. ;-( rider: еще раз: поговори с теми, кто это делает, а не со мной. Они сейчас в отпуске. ab: дык ты же меня уговаривал на прошлой неделе вынести модули IDE из ядер... пропатчив все что детектит rider: потому что на прошлой неделе все были здесь и были готовы разговаривать на эту тему и делать эту работу. То, что ты отреагировал не на следующий день, как обещал, а через неделю -- увы, сейчас их нет. ab: у меня были другие дела ;-( теперь у нас другие :-( Мне сегодня нужно security updates собирать, а я с тобой здесь спорю. :-( UlfR: ладно, ab ушел от ответственности... ты то что скажешь про modutils, ты же патчил - знаешь сложность создания патчей.. да и зачем нужен макроязык тоже знаешь ;-) ab: а я уже собрал свой rider: что ты собрал? rider, а с каких пор это в сизифе (и у тебя) стало котироваться "как у всех"? это серьезный вопрос -- что главнее: "как у всех" или "правильно"? rider, и начсет унификации -- "даешь унификацию макросов rpm!", а остальное уж как-то по мелочам утрясется хотя это -- ключевая точка для девелоперов, которых меньше, но принцип (наблюдаемый) один ab: kernel-image-vs-smp он даже был сформулирован ldv и занесен в фортунки gvy: тут немного о другом спор идет, хотя я тоже сторонник унификации макросов ;-) gvy: я имею в виду междистрибутивную унификацию gvy: я думаю, что мы когда-нить получим унификацию макросов.. хотя я могу и ошибаться. rider, я прекрасно понимаю. но в данном случае на 100% согласен с ab (вовсе не из позиции вида "все, что сказал rider -- чушь и его надо кунуть"). rider, попросту говоря -- если я что-то задвигал в апстримы, то как раз *на основании* обкатки в дистро а тут -- критичный компонент ab, rider -- но в lkml однозначно надо отсигналить. всякую ^&*^&* обсуждать время им есть -- значит, на важный (вроде этого) вопрос тоже найдется gvy: я тоже согласен с ab, но ресурс на это выделять тяжело rider, а если оно уже? gvy: судя по словам ldv оно еще далеко не уже rider: отрезать язык -- не добавить. я сразу отписывал, что варианта два. 1. патчить mu и вести их, 2. патчить mit и вести их. По сложности -- примерно одинаково. Про тактику и стратегию развития mu/mit Саша уже говорил. Ну конечно есть вариант вообще ничего не делать -- типа само утресётся. gvy: да какая разница, что там думает lkml ? ненулевое количество пользователей alt-based distro консоли-то не видят. И это число, к прискорбию, будет увеличиваться. lioka, это еще один довод, но они как раз ничего и не решают, так? UlfR: может быть третий вариант и выбрать, параллельно добивая авторов modutils и mit до унификации ? gvy: это не довод ;-( rider, практика показывает, что утрясается обычно хуже, чем хотелось. заметь, иначе бы нам тут и говорить было не о чем решают те, кто саппортит. rider: я бы тогда вообще дистрибутив не делал. Все когда-нибудь в RH или Debian утрясется. именно, в итоге ab: согласен Тут я уже видел apt для RH. Ждем? :-) gvy: давай я в тебя брошу новую версию mit и ты ее синхронизируешь с modutils... я просто не понимаю, зачем нам нужна _реально_ никому не нужная функциональность ? а 'майнстримового' саппорта не бывает. period rider, не надо в меня всяким бросаться rider: новую это какую? rider, функциональность, про которую говорит ab -- нужна им и нужна мне. чем плохо забивать на партнеров и их мнение -- лучше не будем вспоминать rider: мне эти действия пока интересны тем, что больше так никто не делает, а потом идет по нашим же следам в своих дистрибутивах. Как только станет очевидно, что здесь уровень сопротивления выше того, который я могу себе позволить бороть, я отсюда уйду. Возможно вообще из дистрибутивов. UlfR: module-init-tools-0.9.15-pre4.tar.bz2 rider: это не новая ;) gvy: расскажи хоть ты мне - зачем тебе нужен макроязык ? UlfR: ;-) rider, вспомни -- есть железки, которые "в розницу" (по компонентам, выуживая с pci) вроде и получается настроить -- да только из-за специфических ляпов _в сумме_ оно не работает UlfR: значит ту, которая не вышла ;-) rider: у меня последняя module-init-tools-3.0-pre9.tar.bz2 gvy: ну и что, а макоязык тут при чем ? Упс, действительно уже есть 3.0-pre9 rider, сделай еще как-то. я просто знаю, что ab и Grigory про это думают, а ты -- перегружен rider, и в итоге часто допускаешь ошибки по таким точкам gvy: мы делаем, потому и перегружены gvy: ладно, бог с ним.. еще для чего нужен макроязык ? rider, ну так делать-то надо то, чего нет или что есть недоделанное минчанам надо -- пусть сделают, они-то на команду оглядываются gvy: мы делаем то, что считаем нужным. gvy: для наших клиентов gvy: ладно, зачем еще макроязык нужен ? rider, для поддержки уже имеющихся /etc/modules.conf (в уже имеющемся объеме оного языка) gvy: а зачем ? в течение жизненного цикла 2.4 gvy: ну так оно будет поддерживаться старыми modutils .. какие проблемы ? gvy: еще зачем ? для _единообразной_ поддержки. rider, повреь -- мне чхать на "прихедших с suse/2.6" по одной простой причине: gvy: а где же ты тогда был, когда переименовывали conf.modules в modules.conf во всех дистрибутивах ? ты говоришь так, как будто уже есть suse/2.6 и там _сделан_ этот выбор; они будут или _знать_ про то, как это было с 2.4 (=> опытные), gvy: нет, а ты говоришь так, как будто мы уже сделали выбор и нам некуда дальше двигаться. или быть пыонерами из-за YaST, которым фиолетово (redhat-config, ...) так вот если говорить о переносе опыта -- то IMVCO более ценно в течение ближайших двух (минимум) лет gvy: я не понял про YaST сохранить опыт тех людей, которые в курсе про modules.conf и "как это с 2.4" gvy: ;-) rider, ну, "те, которые консоли не видят" (которым в общем пофиг, лишь бы работало) понимаешь? gvy: ты посмотри сначала на разницу между modutils и mit ;-) rider, я смотрел где-то при 2.5 gvy: на самом деле, как это с 2.2, а то и раньше. rider, и если ты не в курсе -- собирал m-i-t пакетил gvy: ;-) и уже по N-му кругу думаю над этими граблями потому что тогда тоже обнюхивал, как в cooker/rawhide/pld понимаешь? ;-) ab, отож. rider, т.е. мы можем, _наоборот_, заявить, что у нас этот опыт сохранен и применим а эти идиоты полромали -- ну так это проблемы _их_ клиентов gvy: а нам думать уже все.. некогда ;-( Время ушло на раздумья. Подумали, хватит ... есть мантейнер - пускай принимает решение. А пакет на этой неделе должен быть в Sisyphus в рабочем виде rider, мож я ослеп, но то, что на people/ed/ -- у меня дома и в конторе работает надо посмотреть, где мог костылями подпирать, пока алиасов не наделали... gvy: оно у меня тоже работает - иди докажи это ldv rider: между прочим, наш modutils, в отличие от еще не собраного федориного варианта, на сизифе уже обкатан. rider: что касается ldv, то пока что от него ни одного замечания по этим патчам нет. Как факт. rider, а где можно ознакомиться с претензиями ldv? в devel-kernel@ было? ab: верю, сам на нем сижу.. иди доказывай это ldv. ab: и пакета в Sisyphus тоже нет rider, ну позови его сюда, что ли :-) gvy: зови сам, мне это нахрен не нужно.... * rider is away: Я занят gvy: а багов в том патче есть... как, впрочем, и в чистом mit rider: я не собираюсь доказывать ничего тому, кто не хочет обсуждать. Это пагубная практика. Я только от тебя узнал, что он в этих патчах "сомневается". rider, попробую по крайней мере написать всем почтой vsu, баги всегда есть vsu: ошибки, как ты понимаешь, есть везде. Пуристами быть не приходится. точнее, я сейчас этот кусок перешлю в d-k@ vsu: факт в том, что пакет работает, в том числе и со старыми ядрами. Проблем с ними не замечено. * lioka .oO (rider занят. мы -- так, шаро$#%мся) lioka, да=-да, вот именно <-- rider has quit ("Вышел из XChat") * ab в расстроенных чувствах собирается домой. Через час. vsu: так млин, написали бы, где -- пофиксили бы... UlfR: точнее, там кое-где изврат какой-то написан - работает правильно, но... а вот в get_kernel26_info заложена мина vsu: "там кое-где изврат какой-то написан" -- где можно, я подумаю как это сделать нормально. мина в чём? UlfR: ldv особо понравился код if (obj_find_section(f, "__ksymtab_strings") != NULL) и то, что дальше :) UlfR: а мина - n_module_stat = nmod = ret = 256; //временно vsu: мину разминировать? UlfR: я этот кусок переписал, но ещё не пробовал - сейчас кину --> rider (~rider@altlinux.balabanovo.ru) has joined #altlinux ab, UlfR, vsu, rider -- никто от вышесказанного не отказывается? дочищу и в d-k@ чтоб Диме было на что ссылаться UlfR: поймал? UlfR: да ладно, в mit ошибки ещё более классические :) vsu: ну с миной понятно, но чем так if (obj_find_sec... понравился? --aznLbwQ42o7LEaqN-- --pN9MePJoZbRKbUk1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAJ8EFbsPDprYMm3IRAkUFAJ4jTKuv0v/1rR0uO1qHeaNt4fzwrQCdHt0O XA77pL/eKAM36+Wibi/hyaA= =6/zn -----END PGP SIGNATURE----- --pN9MePJoZbRKbUk1--