Bug 2774

Прочитал раздел документации "Настройка совместной работы по протоколу CIFS"

Особо вопросов у меня нет, разве что пара замечаний:

0. В подразделе "Монтирование сетевого ресурса" про noperm как-то можно поакцентированнее рассказать.

1. В подразделе "Соответствие версий WINE@Etersoft и CIFS" не совсем понятна фраза:

Новый WINE по названию модуля (через файл/sys/module/etercifs/version) умеет определять, наш ли модуль cifs загружен.

Я бы сократил её до:

Новый WINE по названию модуля умеет определять, наш ли модуль cifs загружен.

Процитирую себя из: http://bugs.etersoft.ru/show_bug.cgi?id=2782#c4

Фразу:

При вызове build можно указать путь к заголовочным файлам ядра для сборки: KRNSRC=/usr/src/путь service etercifs build. Или только версию ядра: KERNELVERSION=2.6.26-std-pae /etc/init.d/etercifs build.

Предлагаю изменить на:

При вызове build можно указать версию ядра, отличного от текущего, для которого требуется собрать модуль (для него должны быть установлены заголовочные файлы ядра): KERNELVERSION=2.6.26-wks-smp-alt1 /etc/init.d/etercifs build.


Пояснение: Только KERNSRC без KERNELVERSION указать нельзя, потому что если не указать KERNELVERSION, он возьмется из текущего ядра. И без указания KERNSRC нельзя просто написать KERNELVERSION=2.6.26-wks-smp, надо указать ещё и релиз, т.е. KERNELVERSION=2.6.26-wks-smp-alt1. Это связано с тем, что если не указано KERNSRC, то KERNSRC=/lib/modules/$KERNELVERSION/build и $KERNELVERSION в данном случае должна иметь формат такой же, как вывод uname -r для данной системы.

Можно, конечно, указать обе переменные типа:

KERNSRC=/usr/src/linux-2.6.26-wks-smp KERNELVERSION=2.6.26-wks-smp service etercifs build

И в таком случае не указывать релиз. Но это как-то по-моему неудобно и только запутает пользователя. Да и должен же человек осознавать для какого именно релиза ядра он модуль собирает!

Кстати, в этой фразе есть неточность - переменная указана вместо KERNSRC - KRNSRC, так что все равно править.

(In reply to comment #2)
> Можно, конечно, указать обе переменные
> типа:
> 
> KERNSRC=/usr/src/linux-2.6.26-wks-smp KERNELVERSION=2.6.26-wks-smp service
> etercifs build
> 

Нет. В таком случае модуль появится в папке /lib/modules/2.6.26-wks-smp/kernel/fs/cifs/ что на мой взгляд ошибочно.Предлагаю вообще не писать про KERNSRC и указывать полный KERNELVERSION, с релизом.

(In reply to comment #3)
> Предлагаю вообще не писать про
> KERNSRC и указывать полный KERNELVERSION, с релизом.
> 
Такое теоретически может пригодиться в случае, когда мы собираем модуль для текущего ядра, но нет ссылки /lim/modules/`uname -a`/build на исходники. Такое я видел вчера в Мандриве, но там без dkms все равно никак, так что смысла в этом немного. Возможно есть ещё случаи использования, в таком случае нужно добавить про это фразу в документацию. Типа:

Если вы собираете модуль под текущее ядро, но хотели бы указать расположение заголовочных файлов исходников ядра, то для этого следует использовать переменную KERNSRC.

Выложил на http://git.etersoft.ru/people/kipruss/private/wine-etersoft-docs.git свои правки того куска документации, который касается CIFS. То есть правился файл user_manual/cifs.m-k

Переделок довольно много и я буду благодарен за прочтение и критику. Тем более, что я сегодня уже не успею овладеть инструментарием, который конвертирует это все в HTML, чтобы посмотреть на готовый продукт. Так что разметку верстал "вслепую".

Добавил 1 абзац про DKMS. Просьба отписаться о порядке размещения? Может ещё какие действия надо предпринимать чтобы применить изменения? Или просто подождать, когда будет очередное общее обновление документации?

Просьба перед публикацией своего репозитория не забывать делать git pull с моего.
Ещё можно научить меня правильно сравнивать :)
я делаю
git fetch kipruss
git diff kipruss/master

(In reply to comment #7)
> Просьба перед публикацией своего
> репозитория не забывать делать git pull с
> моего.

Виноват. Исправлюсь. :)

> Ещё можно научить меня правильно
> сравнивать :)
> я делаю
> git fetch kipruss
> git diff kipruss/master
> 

Я ещё и файлы вытягиваю в отдельный бранч
например, есть у меня репозиторий cifs-2.6, а в нем бранч stable-2.6.25
у репозитория имеются remote, в том числе и stable-2.6.25 (то, что названия совпадают, надеюсь, не запутает. Зато из жизни пример)

Вот так я обновляюсь (сперва перехожу в этот бранч):

git checkout stable-2.6.25
git fetch stable-2.6.25 master:stable-2.6.25 && git checkout -f stable-2.6.25

затем я сравниваю по тегам, но если надо сравнить бранчи, то, например, так:

git diff stable-2.6.25 v2.6.25-etercifs

а ещё точнее, чтоб из жизни (сравнивать только указанные папки):

git diff stable-2.6.25 v2.6.25-etercifs -- fs/cifs

Можно, наверное, оптимальнее.

(In reply to comment #8)
> Вот так я обновляюсь (сперва перехожу в
> этот бранч):
> 
> git checkout stable-2.6.25
> git fetch stable-2.6.25 master:stable-2.6.25 && git checkout -f stable-2.6.25

Вот, стоило опубликовать, как после обновления git-core запретили фетчиться в текущий бранч. Теперь выводится сообщение:

fatal: Refusing to fetch into current branch

Теперь, значит так:

(мы находимся НЕ в бранче stable-2.6.25)
git fetch stable-2.6.25 master:stable-2.6.25

теперь, если мы хотим перейти в бранч для просмотра файлов, то

git checkout stable-2.6.25

И уже git checkout -f делать не надо. Можно сравнивать. В принципе для сравнения и переходить-то в бранч не надо.

Документация обновлена, находится в git.eter, дальнейшие изменения - в рабочем порядке.

Добавил некоторую информацию.

http://git.etersoft.ru/people/kipruss/packages/?p=wine-etersoft-docs.git;a=commitdiff;h=fb95062d31d2b6a2c7593934ca1c600c5d3b1de2