Всем доброго времени суток.

Собственно по ходу освоения Linux/Unix возник ряд вопросов
(на данном этапе скорее теоретических), связанных с субжем.

1. Каким образом внутренние сущности приложения (н-р, демона)
могут быть выставлены наружу в виде иерархии каталогов, для
общения с ним других приложений?

2. Можно ли реализовать озвученное в п. 1 посредством виртуальной
файловой системы?

3. Исходя из п.2: какие существуют ограничения на код, реализующий
файловую систему (что он может, к чему (каким системным сервисам)
может обращаться, что такому коду недоступно)?

4. Чисто в форме теоретического вопроса (вытекает из п. 3): можно ли
БД в СУБД представить в виде файловой системы и заставить ls/cd/vim
работать с этим монстром?

5. Существуют ли примеры/ссылки на примеры, реализующие подобный
подход композиции приложений?

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

С Уважением.

Filesystem in user space может быть тебе поможет
там правда несколько иной подоход: ӕта штука поможет тебе создавать VFSы которые надо монтировать... собственно при монтировании ФС запускается твое приложение и работает до тех пор пока ФС примотирована.

если хочется из демона ӕкспортировать некую иерархию... думаю придется покапать FUSE на предмет ее взаимодействия с ядром и повторить ӕто в своем демоне

Здравствуйте, wf, Вы писали:


wf>Всем доброго времени суток.

wf>Собственно по ходу освоения Linux/Unix возник ряд вопросов
wf>(на данном этапе скорее теоретических), связанных с субжем.

Практически на все эти вопросы один ответ — FUSE (Filesystem in userspace). Реализации есть как минимум для Linux и FreeBSD. В виде файлового дерева можно выставить что угодно, но нужно отрабатывать протокол VFS (он различный для различных систем).

Впрочем, можете попробовать и в драйвере что-то сделать.

wf>3. Исходя из п.2: какие существуют ограничения на код, реализующий
wf>файловую систему (что он может, к чему (каким системным сервисам)
wf>может обращаться, что такому коду недоступно)?
Ограничений почти нет.

wf>5. Существуют ли примеры/ссылки на примеры, реализующие подобный
wf>подход композиции приложений?

Ну вот во FreeBSD'шных портах

wf>4. Чисто в форме теоретического вопроса (вытекает из п. 3): можно ли
wf>БД в СУБД представить в виде файловой системы и заставить ls/cd/vim
wf>работать с этим монстром?

$ ls -ld */fusefs*
drwxr-xr-x 2 root wheel 512 Nov 1 10:49 graphics/fusefs-gphotofs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-curlftpfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-encfs
drwxr-xr-x 3 root wheel 512 Mar 6 11:20 sysutils/fusefs-funionfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-gnome-vfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-httpfs
drwxr-xr-x 3 root wheel 512 Mar 6 11:20 sysutils/fusefs-kmod
drwxr-xr-x 2 root wheel 512 Feb 14 08:46 sysutils/fusefs-libs
drwxr-xr-x 3 root wheel 512 Mar 6 11:20 sysutils/fusefs-ntfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-smbnetfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-sqlfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-sshfs
drwxr-xr-x 3 root wheel 512 Feb 14 08:46 sysutils/fusefs-unionfs
drwxr-xr-x 2 root wheel 512 Feb 14 08:46 sysutils/fusefs-wdfs

по-моему, достаточно чтобы набрать примеров:) Кстати, sqlfs там уже есть:)

N> Ну вот во FreeBSD'шных портах

Спасибо большое за развернутый ответ, действительно достаточно.
Общее направление движения понятно.

Здравствуйте, zaufi, Вы писали:

Z> если хочется из демона ӕкспортировать некую иерархию...
Z> думаю придется покапать FUSE на предмет ее взаимодействия с
Z> ядром и повторить ӕто в своем демоне

Спасибо! Посмотрю Fuse.
Вобщем виртуальные файловые системы выглядят красивым
способом организации общения приложений, как раз в рамках
идеологии Unix-Way. Конечно открыты вопросы быстродействия и
удобства реализации необходимых протоколов.

Здравствуйте, wf, Вы писали:

Прямо как чувствовали. На ЛОРе выложили ссылку на статью
.здесь

Здравствуйте, wf, Вы писали:

wf>1. Каким образом внутренние сущности приложения (н-р, демона)
wf>могут быть выставлены наружу в виде иерархии каталогов, для
wf>общения с ним других приложений?
А зачем? Не проще ли открыть сокет и сгородить простой текстовый протокольчик?
Если для общения с ядром этот подход еще туда-сюда, то заставлять так общаться два
юзермодовых приложения -- уже попахивает извращением.

wf>4. Чисто в форме теоретического вопроса (вытекает из п. 3): можно ли
wf>БД в СУБД представить в виде файловой системы и заставить ls/cd/vim
wf>работать с этим монстром?
Можно, но зачем? Оверхед подобного подхода хорошо представляешь, да?

wf>5. Существуют ли примеры/ссылки на примеры, реализующие подобный
wf>подход композиции приложений?
Именно через vfs -- нет. Под маком, например, есть netinfo (как пример иерархической базы данных), но там для доступа не vfs, а своя утилита.

Здравствуйте, Аноним, Вы писали:

wf>> 1. Каким образом внутренние сущности приложения (н-р, демона)
wf>> могут быть выставлены наружу в виде иерархии каталогов, для
wf>> общения с ним других приложений?

> А зачем?

Например, для того, чтобы работать с ними посредством большого количества
существующих приложений, используя традиционный для *nix подход на основе
"все есть файл".

> Не проще ли открыть сокет и сгородить простой текстовый протокольчик?

Проще. Потому с этим и не возникает никаких вопросов.

>4. Чисто в форме теоретического вопроса (вытекает из п. 3): можно ли
wf>> БД в СУБД представить в виде файловой системы и заставить ls/cd/vim
wf>> работать с этим монстром?

А> Можно, но зачем? Оверхед подобного подхода хорошо представляешь, да?

Конечно представляю. Ключевое сочетание здесь _Чисто_в_форме_теоретического_вопроса_.

Вобщем, спасибо! Понятно.

Здравствуйте, wf, Вы писали:

wf>Здравствуйте, Аноним, Вы писали:

wf>>> 1. Каким образом внутренние сущности приложения (н-р, демона)
wf>>> могут быть выставлены наружу в виде иерархии каталогов, для
wf>>> общения с ним других приложений?

>> А зачем?

wf>Например, для того, чтобы работать с ними посредством большого количества
wf>существующих приложений, используя традиционный для *nix подход на основе
wf>"все есть файл".

Хорошо, расшифровываю вопрос. Модель данных какой предметной области хорошо представляется в виде файловой системы?
Вопрос без подвоха, на самом деле, мне самому интересно.

Здравствуйте, <Аноним>, Вы писали:

А>Хорошо, расшифровываю вопрос. Модель данных какой предметной области хорошо представляется в виде файловой системы?

Имхо что угодно. Но надо уметь остановиться вовремя.

Здравствуйте, Аноним, Вы писали:

А> Хорошо, расшифровываю вопрос. Модель данных какой предметной
А> области хорошо представляется в виде файловой системы?
А> Вопрос без подвоха, на самом деле, мне самому интересно.

Хм. Отвечаю не очень конкретно, так как практического
примера, где можно было бы прикрутить подобный метод
взаимодействия у меня нет — вопрос изначально носил
"теоретический" характер. Файловая система — иерархия. В виде
иерархии можно представить если и не все, то очень многое.
Не обязательно это именно модель данных предметной области.
Это могут быть внутренние структуры приложения,
обрабатывающего какие-либо данные: н-р, очереди, статистика
работы. Конечно понятно, что все это может располагаться в
файловой системе в виде реальных каталогов и файлов, а не
виртуальных, но это известный способ организации обмена.
Мне же было интересно как это же самое организовать посредством
виртуальной ФС.

Здравствуйте, zaufi, Вы писали:

Z>там правда несколько иной подоход: ӕта штука поможет тебе создавать VFSы которые надо

Как вы так делаете? И зачем?

Здравствуйте, wf, Вы писали:

wf>Здравствуйте, Аноним, Вы писали:

wf>"теоретический" характер. Файловая система — иерархия. В виде
wf>иерархии можно представить если и не все, то очень многое.
wf>Не обязательно это именно модель данных предметной области.
wf>Это могут быть внутренние структуры приложения,
wf>обрабатывающего какие-либо данные: н-р, очереди, статистика
wf>работы. Конечно понятно, что все это может располагаться в
wf>файловой системе в виде реальных каталогов и файлов, а не
wf>виртуальных, но это известный способ организации обмена.
wf>Мне же было интересно как это же самое организовать посредством
wf>виртуальной ФС.

Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно. А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.

Здравствуйте, Quintanar, Вы писали:

Q>Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно.

Дададад. Исключительно синхронно. Вы притворяетесь или реально не понимаете, насколько сложные механизмы внутри ОС стоят за "простыми" операциями над FS?

Или Вы собрались реализовывать преобразование состояния процесса в кусок реальной FS на лету, с апдейтом по каждому мелкому чиху?

Q> А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.

MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Quintanar, Вы писали:

Q>>Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно.

N>Дададад. Исключительно синхронно. Вы притворяетесь или реально не понимаете, насколько сложные механизмы внутри ОС стоят за "простыми" операциями над FS?

N>Или Вы собрались реализовывать преобразование состояния процесса в кусок реальной FS на лету, с апдейтом по каждому мелкому чиху?

Хм. А что, дорожка "утиль -> fs -> fuse (или что там) -> демон" и выгребание состояния демона каким-то образом короче?

Q>> А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.

N>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?

Из за технических проблем. А разве нет?

Здравствуйте, wf, Вы писали:

wf>Здравствуйте, Аноним, Вы писали:

А>> Хорошо, расшифровываю вопрос. Модель данных какой предметной
А>> области хорошо представляется в виде файловой системы?
А>> Вопрос без подвоха, на самом деле, мне самому интересно.

wf>Хм. Отвечаю не очень конкретно, так как практического
wf>примера, где можно было бы прикрутить подобный метод
wf>взаимодействия у меня нет — вопрос изначально носил
wf>"теоретический" характер. Файловая система — иерархия. В виде
wf>иерархии можно представить если и не все, то очень многое.
Ну, хорошо. Представить, действительно, можно многое. А вот будет ли иерархия лучше других, т.е. "хорошо представлять" -- это еще вопрос.

wf>Не обязательно это именно модель данных предметной области.
wf>Это могут быть внутренние структуры приложения,
wf>обрабатывающего какие-либо данные: н-р, очереди, статистика
Очереди для сервера тасующего туда-сюда данные (и не вдумывающегося в их смысл) -- вполне себе предметная область. Вопрос-то в другом.
Допустим, статистика каких-нибудь очередей или каналов данных. Как будем строить иерархию. По источнику? По приемнику? Городить что-то вроде

xxx/source/id/0
xxx/source/id/1
...
xxx/source/id/34545
xxx/source/name/foo
xxx/source/name/bar
...

(и потом еще столько же под xxx/target/...) -- этот весь геморрой нужен? Ради чего, ради возможности походить по иерархии с помощью mc?

Здравствуйте, Eugene Kilachkoff, Вы писали:

Q>>>Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно.
N>>Дададад. Исключительно синхронно. Вы притворяетесь или реально не понимаете, насколько сложные механизмы внутри ОС стоят за "простыми" операциями над FS?
N>>Или Вы собрались реализовывать преобразование состояния процесса в кусок реальной FS на лету, с апдейтом по каждому мелкому чиху?
EK>Хм. А что, дорожка "утиль -> fs -> fuse (или что там) -> демон" и выгребание состояния демона каким-то образом короче?

По крайней мере эффективнее (и значительно), если в демоне постоянно что-то происходит, а контроль или управление производится периодически по мере необходимости.

Q>>> А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.
N>>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?
EK>Из за технических проблем. А разве нет?

А откуда эти проблемы возникли? Именно из-за того, что пытались на уровне VFS совместить работу с двумя источниками активности — внутренним (обновления устройств) и внешним (чтение/запись devfs из userland), и у них не получилось.
Хотя чем udev значительно лучше — мне не понять.

Здравствуйте, netch80, Вы писали:

N>Хотя чем udev значительно лучше — мне не понять.

Например, имена файлов устройств и права на них определяются в userspace.

Здравствуйте, netch80, Вы писали:
N>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?
Потому что была заменена более новым udev'ом, в котором можно конфигурировать наааааааамного больше всего, чем в devfs.

Здравствуйте, ДимДимыч, Вы писали:

ДД>Здравствуйте, netch80, Вы писали:

N>>Хотя чем udev значительно лучше — мне не понять.
ДД>Например, имена файлов устройств и права на них определяются в userspace.

Ну я на freebsd это могу и для devfs сделать. Средствами ядра (devfs, devfs.conf...) А чем userspace тут настолько лучше?