[Devel] Etercifs 5.0.0

[Evgeny Sinelnikov]

12 января 2011 г. 21:02 пользователь Pavel Shilovsky
<piastryyy на gmail.com> написал:
> 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-2.6.32-5.0.0, наверное...


> оставляет сомнений, где можно использовать этот пакет.
>

смотря у кого... Вот поставил я дистрибутив Ubuntu 10.10. Откуда я
узнаю какой пакет ставить?

 А если у меня обновление придёт с новой версией ядра, как это в
Федоре часто бывает, как быть? Ставить новую версию? А если у меня
пара разных версий ядра? Переставлять разные версии etercifs?

Логично, в таком случае, выделить общую часть и пакеты с исходниками.
Тогда можно сделать пакеты
 etercifs-ubuntu-10.10
 etercifs-fedora-14
 ...
которые будут тянуть за собой всё, что нужно.


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


Такие модули можно было бы складывать в соответствующие
 etercifs-ubuntu-10.10
 etercifs-fedora-14
 ...
которые я упоминал выше. Но как быть с обновлёнными ядрами? Будем,
считать, что сборка драйвера для ядер из обновлений будет проходить
как обычно?

>> Данный набор компромиссов может быть реализован и в предлагаемом в документы
>> подходе с таким условием, что ограниченно поддерживаемые дистрибутивы не
>> удаляются из списка устанавливаемых исходников, а только помечаются, как не
>> поддерживаемые.
>>
>> Вообще, сейчас 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 собираются из баг-фиксов.

Потенциально проблемы возможно между *.*.*.y и *.*.*.y+1, хотя и
маловероятны. Но ведь для дистрибутивостроителей это нет так. У них
2.6.18 может оказаться больше похожим на 2.6.24. Как здесь быть? Снова
указываю на вариант вида:
 etercifs-ubuntu-10.10
 etercifs-fedora-14
 etercifs-centos-5.2
 etercifs-centos-5.3
 ...

Но как это всё поддерживать? Как пересобирать коринфом кучу разных
пакетов из разных веток? Стоит ли это всё в разных ветках держать?
Может быть отдельно исходники, отдельно дистрибутивы, отдельно общие
файлы со скриптами?


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

Я уже задавал выше это вопрос. Как же быть с обновлёнными ядрами? Как
же быть с разными версиями ядра в одной системе? Как быть с etercifs,
например, для Федоры, если после установки у неё одна версия ядра, а
после обновления - другая?



-- 
Sin (Sinelnikov Evgeny)
Etersoft