fuse без mount(fusemount), то есть без ядра

>к демону fuse
Что?
Обычно fuse монтируют отдельными утилитами, в зависимости от типа ФС.

то есть без ядра

Ядро в этом не участвует, на то оно и file system in user space.
mount передаёт управление на юзерспейсный хелпер. Называется обычно mount.<название_фс>.

> Ядро в этом не участвует, на то оно и file system in user space.

Участвует, очень даже. В userspace там лишь сам код FS. А вот запросы к нему отправляет ядро.

Отдельные mount для разныз FS там потому что сисколл mount имеет возможность передать доп параметры драйверу fs , при чем в виде некоего блоба. Вот этот самый блоб для каждой FS свой - его то и формирует команда smbmount например или mount.чтототам

> Никак не могу найти - можно ли

Можно. Как и к любой другой программе... Которая умеет это

и как если можно, коннектится к демону fuse

К которому из них? приложение <-> syscall(файл) <-> ядро <-> fuse(протокол) <-> fuse-бакэнд. Чтобы прицепиться к бакэнду, нужно чтобы бакэнд это умел. Например, для бакэнда gvfs-fuse-daemon (которые через fuse монтирует ~/.gvfs) есть множество всяких команд gvfs-*. Если у вас примонтирована куча fuse-ресурсов, то с бакэндом каждого из них договариваться надо индивидуально.

> Можно. Как и к любой другой программе... Которая умеет это

Раз ядро вызывает плагины по некоему универсальному протоколу я надеялся что есть способ использовать эти плагины по этому же протоколу но «без ядра». А не как к «любой другой программе... Которая умеет это»

К которому из них? ...

К бекэндам хотелось бы, точнее некую программу которая бы вызывала бекенды и играла роль ядра.

Если у вас примонтирована куча fuse-ресурсов, ...

Я как раз вообще не хочу монтировать ресурсы, я хочу вызвать FS плагин fuse без mount и без ядра. И не из под рута.

> я хочу вызвать FS плагин fuse без mount и без ядра. И не из под рута.

Ну, если мне хотелось нетрадиционных утех (с FUSE), то я бы пошла таким путем:
1. Разобрала пример кода какого-нибудь не слишком сложного бэкэнда http://fuse.sourceforge.net/helloworld.html и документации и how-to по ссылке http://www.ibm.com/developerworks/ru/library/l-fuse/index.html
2. Написала бы небольшую библиотеку, в которой перекрыла fuse_main в которой бы открыла сокет и начала трансляцию событий и данных сокет <-> функции из fuse_operations
3. Вызвала бы бакэнд, «скормив» ему свою бибилиотеку с fuse_main через LD_PRELOAD
Детская задачка, в общем-то :-)

А зачем, можно полюбопытствовать?

> А зачем, можно полюбопытствовать?

Хочу единую файловую систему с VPS хостингами(и в аналогичных условиях). То есть, есть некая система состоящая из процессов на разных узлах. Данные к этим всем процессам хотелось бы хранить единообразно. К fuse уже есть множество плагинов, не надо думать о написании своих велосипедов вроде sshfs. В простых случаях, а особенно в нишебродских случаях ;) вообще какой нибудь gmailfs будет достаточен. Админ системы(точнее тот кто ее развертывает) будет уже решать какие способы хранения удобны для конкретной инсталляции.

Соответственно расширением идеи будет wrapper через LD_PRELOAD который перехватывает обращения к файлам и перенаправляет их к fuse-плагину. Это в том случае если fuse в системе нет и поставить можно только user level ее часть.

Я как бы думал что fuse гибче и ее можно будет использовать таким образом. Я уж вспоминая gnu/hurd организацию file system in userspace думал что fuse позволяет на user level делать стек файловых систем, то есть без помощи ядра их друг к другу присоединять. Ну и думал что утилиты для доступа без помощи ядра уже есть. Или хотя бы в архитектуре fuse этот момент продуман.

Судя по тому что прочитал там они работают с /dev/fuse и даже этот файл поменять нельзя.

> Детская задачка, в общем-то :-)

По моему проще патч к libfuse и демон играющий роль ядра для запуска fuse плагинов. При чем патч будет состоять из возможности указать другой коммуникационный файл, ну и отразить разницу между файлом устройства /dev/fuse и сокетом, если она есть(имхо ее нет в данном случае). Такой патч скорее всего примут и в мейнстрим, тем более что совместимость он не нарушит.
Я исходники не читал еще (не уверен что готов идти этими «простыми» путями :)), так что не знаю, может там уже есть возможность указать вместо /dev/fuse чтото другое.

Тогда не надо будет разбираться с перехватом операций, и можно будет просто написать демон - серверную часть по документации.