From: Sergey Vlasov <vsu@altlinux.ru> To: ALT Linux kernel packages development <devel-kernel@altlinux.ru> Subject: Re: [d-kernel] Q: modutils vs module-init-tools Date: Tue, 10 Feb 2004 17:34:04 +0300 Message-ID: <20040210143404.GA29008@master.mivlgu.local> (raw) In-Reply-To: <20040210125100.GB3421@basalt.office.altlinux.org> [-- 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 --]
next prev parent reply other threads:[~2004-02-10 14:34 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-02-09 17:19 [d-kernel] q: " Michael Shigorin 2004-02-09 17:24 ` Anton Farygin 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 [this message] 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=20040210143404.GA29008@master.mivlgu.local \ --to=vsu@altlinux.ru \ --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