[Devel] Etercifs 5.0.0

Чт Янв 13 10:34:33 MSK 2011

12 января 2011 г. 23:39 пользователь Evgeny Sinelnikov
<sin на altlinux.ru> написал:
> 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-2.6.32-5.0.0, когда
etercifs-2.6.32 - название пакета.

>
>
>
>>>
>>> Главное изменение в подходе к выпускам - это разбиение поддерживаемых ОС по
>>> разным выпускам 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@
мы разбиваем etercifs на две части. Одна общая со скриптами
(etercifs-common) и вторая с исходниками (etercifs-sources). При этом
в системе может быть установлено сколько угодно пакетов
etercifs-sources, но один пакет etercifs-common Общая часть всегда
будет выбирать из них более подходящую для текущей загруженной версии
ядра. Какие же ядра скачивать мы оставляем на пользователя. Если
пользователь может скачать и установить пакет, то версию ядра тоже
сможет посмотреть.

Чтобы упросить пользователю жизнь, то я предлагаю всегда держать
актульным систему каталогов со ссылками на пакеты вида:
Каталог Distros, в нём:
Ubuntu/10.04/
Ubuntu/10.10/
Fedora/13/
Fedora/14/
...
В каждом из них будут ссылки на каталоги исходников для ядер из
данного релиза дистра вида:
(пример для Fedora/13)
sources-2.6.33 -> "../../Kernels/2.6.33/Fedora/13/"
sources-2.6.34 -> "../../Kernels/2.6.34/Fedora13/"

Каталог Kernels, в нём:
2.6.32/Ubuntu/10.04/
2.6.32/Fedora/12/
2.6.33/Fedora/13/
...
В каждом из них будут лежать пакеты вида etercifs-sources-2.6.32-5.x.x.

Каталоги Distros и Kernels будут лежать сразу в каталоге
CIFS на Etersoft. То есть пользователь сможет выбрать себе пакет и по
версии дистра и по номеру ядра (например если ему нужно нестандартное
ядро). Так же пользователь сможет себе выбрать любую версию пакета
вида etercifs-sources-2.6.33-5.x.x. Конечно можно стоит выделить
отдельно stable, testing версии - опять же ссылками в том же каталоге
"Kernels/2.6.33/Fedora/13/"

Ещё как вариант можно сделать метапакеты для версий дистров (как
предложил sin@). Например:
etercifs-fedora-13 будет включать в себя etercifs-common-5.x.x +
(etercifs-sources-2.6.33-5.x.x + etercifs-sources-2.6.34-5.x.x. Это
полностью ликвидирует любую неоднозначность для пользователя. Если же
выходит обновление в текущем релизе дистра, то мы добавляем новые
исходники и потом собираем новую версию метапакета, включающую в себя
старые и новые исходники для этой версии дистра.

Процесс выглядит довольно ёмким в плане поддерживания всей этой
инфраструктуры. Но если мы будем вовремя обновлять список дистров для
каждого пакета исходников (вида etercifs-sources-2.6.32) и
перезапускать скрипты сборки в случае изменений, то проблем быть не
должно.

-- 
Best regards,
Pavel Shilovsky.