Etercifs/history

Материал из Etersoft wiki
Перейти к: навигация, поиск
Wackowiki-logo.png Blue Glass Arrow.svg MediaWiki logo.png
Эта страница была автоматически перемещена с old.wiki.etersoft.ru.
Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки.
Просьба по окончанию убрать этот шаблон со страницы.


История вопроса с CIFS

Модуль ядра Linux под названием cifs был разработан при активном участии компании IBM в рамках проекта под названием linux-cifs. На основе исходных текстов проекта Etersoft собирала пакет linux-cifs, последней стабильной версией которого является linux-cifs-1.50c-alt4 (вернее, это последний релиз, выпущенный Виталием перед экспериментальными изменениями, которые начал производить Евгений).


Но на новых ядрах этот пакет не собирался, поэтому Евгений взял исходники из новой версии cifs и применил наши патчи. В результате пакет (последний релиз - linux-cifs-1.54-alt2) на новых ядрах работает, но нестабильно.


В результате обдумывания этого вопроса возникло предложение следать для каждого ядра свою версию. То есть, я брал исходную версию cifs из каждого конкретного ядра (из git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git ), патчил её, и собирал. Результатом стали пакеты linux-cifs-2.6.23, linux-cifs-2.6.24, linux-cifs-2.6.25. Версию для ядра 2.6.25-std-def-alt7 - из пакета linux-cifs-2.6.25 я тестировал и проблем с падением не заметил (см. http://bugs.etersoft.ru/show_bug.cgi?id=2220#c9 )


В дальнейшем было решено отказаться от нескольких независимых пакетов и выделить отдельно скрипты установки (пакет linux-cifs) и запуска и отдельно - исходники для разных ядер (пакеты kernel-source-etercifs* ) и при сборке автоматически выбирать нужные исходники, если для данного ядра они установлены.


А совсем в дальнейшем, в конце сентября 2008 года было решено вести две версии пакета: старую и новую. В старой версии для Этерсофтовских флагов используются биты 29-31, а в новой - 21-23. Вот одинаковая для всех исходников разница:


diff --git a/cifs/file.c b/cifs/file.c

index b1506ab..7e03334 100644

--- a/cifs/file.c

+++ b/cifs/file.c

@@ -113,7 +113,7 @@ static inline int cifs_get_share_flags(unsigned int flags)

 {

 	if (!etersoft_flag)

 		return FILE_SHARE_ALL;

-	return ((~(flags>>29))&7);

+	return ((~(flags>>21))&7);

 }

 

 /* all arguments to this function must be checked for validity in caller */


То, что было ранее - это старая версия. Название linux-cifs для пакета оставлено.


Новый пакет называется соответственно etercifs. Служба тоже называется etercifs.


Пакеты конфликтуют друг с другом, то есть не могут одновременно стоять в системе.


Далее во всех примерах будет фигурировать etercifs.


Исходники, начиная с версий 3.3 для etercifs и 3.2 для linux-cifs, пакуются в сам пакет, а не отдельно.


Зачем нужен драйвер

В стандарте CIFS есть режим разделения файла, то есть можно блокировать только некоторые действия: чтение, запись, чтение и запись, удаление . Драйвер cifs.ko из ядра Linux не поддерживают эту часть протокола. Патчи Etersofs созданы для решения этой проблемы. В частности, добавляется новые параметр (const int share_flags) в функцию открытия файла CIFSSMBOpen.


Проблемы с блокировками следующие:

  • режим открытия файла (решается расширением параметра функции open)
  • установка блокировок через fcntl (может некорректно транслироваться в CIFS)
  • oplocks (то есть правильное управление кэшированием). Тут самое сложное, потому что должно работать W заблокировал, записал, разблокировал. G заблокировал, прочитал, разблокировал. Важно гарантировать, что G получит новые данные, а не из кэша.


Замечания и пояснения к изменениям

1. Произошло "раздвоение" пакета на linux-cifs и etercifs в связи с изменением флагов в etercifs.

2. Поскольку для каждого ядра - свои исходники, то мы больше не предоставляем в собранном виде драйвер etercifs.ko

3. Удален build.sh и некоторая часть из него перекочевала прямо в спек

4. Удалено ещё много чего ненужного и нужного, чтобы не путаться. Впоследствии, когда понадобится - добавим. Например, для gentoo. Не претендую на то, что это сделано правильно.

5. Теперь архиректура - noarch

6. Сильно поменялся buildmodule.sh. Он теперь лежит отдельно и алгоритм его работы описан далее.



Устаревшее: постановка задачи

Основная задача: сообщить samba-серверу о режиме разрешения другим доступа к файлу, и получить ответ, разрешён ли доступ нам. Из этого следует, что файл должен быть открыт с соответствующими правами.


Из-за реализации открытия файлов в Linux через модуль ядра можно это это сообщить только дополнительным вызовом (при этом придётся повторно открывать файл).

Особая сложность при сообщении о доступе из wineserver - поскольку потребуется открывать файл параллельно с открытием через системный вызов.

Возможно единственный вариант передачи нужной нам информации - через блокировки.


Вариант реализации

Плюсы

Минусы

SAMBA-сервер

Будет работать с любой ОС

Проще всего в реализации - добавить обращение к libwine-etersoft и всё (нельзя из-за GPL)

Требуется сборка сервера под каждую платформу

Неправильное (временное) решение

CIFS-модуль ядра

Может работать с любым CIFS-сервером (и Windows в том числе)

Изменения в CIFS-модуле не страшно отдать под GPL

Будет работать только в Linux

Проблемы со сборкой модулей под все ядра

Всё равно менять wineserver для обращения к модулю

wineserver - реализовать в нём обращение по CIFS

Самый правильный и независимый способ, позволит в дальнейшем всю функциональность реализовать.

Самый сложный вариант, много работы

Нет проверенной клиентской библиотеки (libcli_smb) для SAMBA4 (но есть libsmbclient из SAMBA3 с необходимой функциональностью

Проблема с несовместимостью лицензий (LGPL для wineserver и GPL для libcli_smb)




SAMBA4: обработка открытия файла осуществляется в odb_tdb_open_file, откуда вызывается share_conflict для сверки shared и access.

модуль ядра cifs: CIFSSMBOpen, там заполняются ShareAccess и DesiredAccess

wineserver: файл fd.c, функция check_sharing