From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 10 Feb 2004 17:34:04 +0300 From: Sergey Vlasov To: ALT Linux kernel packages development Subject: Re: [d-kernel] Q: modutils vs module-init-tools Message-ID: <20040210143404.GA29008@master.mivlgu.local> Mail-Followup-To: ALT Linux kernel packages development References: <20040209171901.GS16611@osdn.org.ua> <20040210125100.GB3421@basalt.office.altlinux.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20040210125100.GB3421@basalt.office.altlinux.org> 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: Tue, 10 Feb 2004 14:34:05 -0000 Archived-At: List-Archive: List-Post: --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit 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@? Возьмёшься? --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKOvbW82GfkQfsqIRAl7tAJ9m/J4kkYsIg6oyVyL94NWm5AoAqQCdGzBf +jrEyeFXfLu0RqGYe8gQjd8= =xwS7 -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24--