On Mon, Oct 05, 2009 at 06:57:08PM +0400, Alexander Galanin wrote:
> On Sun, 4 Oct 2009 16:28:39 +0400
> Stanislav Maslovski <stanislav.maslov...@gmail.com> wrote:
>
> > On Sun, Oct 04, 2009 at 02:03:22PM +0400, Alexander Galanin wrote:
> > > Как результат такой перегруженности процесса монтирования, нормальных
> > > средств для работы с демоном HAL нет. "Нормальный" понимается как
> > > "простой", 'понятный" и "скриптуемый".
> >
> > Не так страшен черт, как его малюют. Довольно давно уже (примерно с
> > момента, когда иксы к hal привязали) для себя использую связку из
> > autofs, hald и пары скриптов. До этого использовал связку udev +
> > autofs.
> >
> > Насколько просто, понятно и скриптуемо это решение -- можешь
> > посмотреть сам. Прилагаю tar.gz.
>
> Занятно. Только вот непонятно, зачем нужно ожидание исчезновения
> симлинки из /media.
Это на случай race между cleanup скриптом и отработкой события add в
другом скрипте, или между событиями удаления/добавления в одном
скрипте (точнее, между двумя рейнкарнациями одного скрипта).
Предложения как сделать лучше принимаются. Текущий вариант
остался со времени "proof of concept".
> А также очень хотелось бы узнать документ, из
> которого взяты значения для fdi-файла.
aptitude install hal-doc && w3m /usr/share/doc/hal-doc/spec/hal-spec.html
> А уж совсем хорошо было бы услышать авторское описаие того, как это
> всё-таки работает.
Примерно так:
1. Скрипт hal-autofs-cleanup отрабатывает при добавлении в базу
записи /org/freedesktop/Hal/devices/computer. Это происходит при
каждом (ре)старте hald. Назначение скрипта - удалить битые
символические ссылки, если таковые остались в /media (например,
после зависания компа или падения hald).
2. При втыкании нового устройства hald опрашивает его и приступает к
созданию записи о нем в своей базе. При этом просматриваются fdi файлы
из /etc/hal/fdi/policy (детали есть в документации).
В hal-autofs-policy.fdi у меня сказано, что если воткнутое
устройство является hotplugguble storage c файловой системой vfat
или ext2 (флешки, mmc карты) или removable storage c файловой системой
iso9660 (сидиромы), то:
a) оно помечается в базе, как обрабатываемое autofs (я добавляю свой
идентификатор "autofs" к info.capabilities)
б) добавляется запись об опциях монтирования для обнаруженной
файловой системы (добавляю свой ключ "volume.autofs.mount_options")
в) скрипт hal-autofs назначается обработчиком событий add/remove для
устройств, помеченных идентификатором "autofs"
3. После обработки policy файлов hald запускает только что
зарегистрированный callout скрипт (c $HALD_ACTION=add). Скрипт создает
симлинк в /media, указывающий на динамическую точку монтирования в
/var/autofs/hal/. В качестве имени симлинка и динамической точки
монтирования берется последняя часть HAL UDI (трюк с basename).
4. При попытке обратиться к /media/`basename $UDI` просыпается
automounter (так как симлинк ведет в /var/autofs/hal/, упомянутый в
/etc/auto.master) и запускает map скрипт /etc/auto.hal, который
извлекает из базы HAL
a) блочное имя устройства
б) тип файловой системы
в) мои опции монтирования
и возвращает эту информацию automounter-у. automounter монтирует FS
в /var/autofs/hal/`basename $UDI` с нужными опциями, после чего она
доступна и через симлинк в /media/.
5. При освобождении файловой системы automounter ее
отмонтирует (по истечении таймаута, заданного в auto.master,
у меня 5 сек)
6. При выдергивании флешки hald приступает к удалению записей об
устройстве и вызывает callout скрипт c $HALD_ACTION=remove. Скрипт
удаляет соответствующий симлинк из /media.
--
Stanislav
--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
