[Devel] Etercifs 5.0.0

[Pavel Shilovsky]

12 января 2011 г. 20:24 пользователь Evgeny Sinelnikov
<sin на etersoft.ru> написал:
> Здравствуйте,
>
> Хочу прокомментировать предложенный вариант к выпуску новых версий Etercifs
> http://goo.gl/9HRRF

В процессе обсуждения мы с lav@ решили перейти к ещё более простой
схеме: один пакет - одна версия исходников. Я начал страничку тут:
http://kb.etersoft.ru/Cifs/etercifs_5.0.0

>
> Главное изменение в подходе к выпускам - это разбиение поддерживаемых ОС по
> разным выпускам Etercifs. Например, 5.0.0 поддерживает Ubuntu 10.10, а 5.0.1
> - уже только 11.04. Мне кажется здесь неудобным необходимость поиска
> соответствия между версией ОС и необходимой версий Etercifs. Это ведь
> безусловно усложнит неодходимый набор действий пользователя, добавит
> путаницу и дополнительные вопросы службе поддержки, потребует исправления
> скриптов сборки в коринфе (в одной сборке под разные ОС потребуются разные
> версии Etercifs).

С новым подходом мы этого избегаем. Нумерация etercifs-5.0.0-2.6.32 не
оставляет сомнений, где можно использовать этот пакет.

>
> Аргументом в пользу этого варианта являются упрощение поддержки и уменьшение
> объёма ненужных исходников под другие системы при установке Etercifs на
> конкретную, поскольку Etercifs тащит с собой все исходники под все
> поддерживаемые системы.
>
> Тем не менее, можно ли как-то более мягко подойти к вопросу упрощения
> поддержки Etercifs? Давайте сформулируем основные проблемы усложняющие его
> поддержку сейчас.
>
> Я вижу следующие:
>  - крайне сложно выполнять проверку новых выпусков драйвера на всех новых и
> старых выпусках дистрибутивов, число которых постоянно пополняется. Мы
> просто лишаем себя возможности что-то гарантировать, не ограничивая список
> поддерживаемых систем.
> - Довольно странно устанавливать в систему пакет с драйверами, которые
> никогда не понадобятся, особенно, если их число постоянно растёт.
> - Довольно странно заниматься работой по созданию веток etercifs для
> дистрибутивов, которые мы не в состоянии качественно проверить, и которые с
> малой вероятностью могут понадобиться нашим клиентам.
>

Так и есть. Устанавливая один пакет с одной версией исходников, мы
избегаем этого тоже.

> В связи этим, я вижу следующие компромиссы:
> - Вероятно, стоит разделить дистрибутивы, для которых осуществляется
> поддержка драйвера Etercifs, на три категории:
>  - поддерживаемые дистрибутивы - ограниченный набор дистрибутивоов, которые
> мы самостоятельно тестируем перед выпуском драйвера;
>  - ограниченно поддерживаемые дистрибутивы - более широкий набор
> дистрибутивов, тестирование которых мы предлагаем нашим клиентам. При этом,
> если число заявок на какой-то дистрибутив возрастает, мы переносим исходники
> в категорию поддерживаемых. Кроме того, для непопулярных дистрибутивов мы
> можем отмечать, ограниченно поддерживаемые исходники, как проверенные
> клиентами;
>  - не поддерживаемые дистрибутивы - дистрибутивы, для которых пользователи
> могу самостоятельно скомпилировать драйвер на основе патчей предыдущих
> выпусков Etercifs и патчей к ванильным выпускам ядра, которые мы ведём в
> отдельных ветках.
> - Вероятно, стоит ввести условную сборку rpm для пакета Etercifs с целью
> ограничения списка включаемого в пакет набора исходников. При этом в пакет
> включаются: набор исходников и, желательно, патчей к выпускам ванильных
> ядер, а также набор исходников под конкретные поддерживаемые и ограниченно
> поддерживаемые ядра данного дистрибутива.
> - Вероятно, стоит организовать статическую сборку бинарных модулей etercifs
> под конкретные ядра, конкретных дистрибутивов. с целью упрощения установки
> драйверов, снижению числа вопросов по их сборке,

Да, это хорошая идея.

>
> Данный набор компромиссов может быть реализован и в предлагаемом в документы
> подходе с таким условием, что ограниченно поддерживаемые дистрибутивы не
> удаляются из списка устанавливаемых исходников, а только помечаются, как не
> поддерживаемые.
>
> Вообще, сейчас etercifs содержит следующий список исходников:
> 2.6.16  2.6.24  2.6.26  2.6.28  2.6.30  2.6.32  2.6.34  2.6.36    centos53
> centos55
> 2.6.23  2.6.25  2.6.27  2.6.29  2.6.31  2.6.33  2.6.35  centos52  centos54
> legacy
>
> Этот список не дифференцирован по дистрибутивам, поэтому может оказаться,
> что вчерашний 2.6.32 не будет работать на той же версии дистрибутива, что и
> сегодняшний. Но это случается редко, поскольку мы подменяем все исходники
> cifs и нам требуется только соответствующих интерфейс к ядру данного
> выпуска, который меняется редко.

Обычно интерфейсы не меняют внутри одной версии ядра, потому тут
ошибка маловероятна. Ветки *.*.*.y собираются из баг-фиксов.

>
> С другой стороны, 2.6.32, собранный в дистрибутивы, основанные на этом
> выпуске ядра будет различаться. И вести речь, что он работает во всех
> дистрибутивах не приходится. При этом, вероятность различия интерфейсов в
> разных сборках ядра одного выпуска под разные дистрибутивы выше, чем в
> рамках одного.
>
> В итоге, сейчас заданные версии ядер предполагают определённые версии
> дистрибутивов и, чтобы вести речь о поддержке Ubuntu 10.10 или Ubuntu 11.04
> нужно задать соответствия между исходниками для разных выпусков ядра и
> поддерживаемыми дистрибутивами. Там же можно указать и ограниченную
> поддержку.

В итоге в репозитории etercifs у нас будет заведена ветка под каждую
версию ядра, из которой собирается отдельный пакет.

-- 
Best regards,
Pavel Shilovsky.