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

[Sergey Vlasov]

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@?  Возьмёшься?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/devel-kernel/attachments/20040210/1e330e1f/attachment.bin