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 там уже есть:)
Filesystem in user space может быть тебе поможет
там правда несколько иной подоход: ӕта штука поможет тебе создавать VFSы которые надо монтировать... собственно при монтировании ФС запускается твое приложение и работает до тех пор пока ФС примотирована.
если хочется из демона ӕкспортировать некую иерархию... думаю придется покапать FUSE на предмет ее взаимодействия с ядром и повторить ӕто в своем демоне
Здравствуйте, wf, Вы писали:
wf>Здравствуйте, Аноним, Вы писали:
wf>"теоретический" характер. Файловая система — иерархия. В виде wf>иерархии можно представить если и не все, то очень многое. wf>Не обязательно это именно модель данных предметной области. wf>Это могут быть внутренние структуры приложения, wf>обрабатывающего какие-либо данные: н-р, очереди, статистика wf>работы. Конечно понятно, что все это может располагаться в wf>файловой системе в виде реальных каталогов и файлов, а не wf>виртуальных, но это известный способ организации обмена. wf>Мне же было интересно как это же самое организовать посредством wf>виртуальной ФС.
Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно. А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте.
Собственно по ходу освоения Linux/Unix возник ряд вопросов
(на данном этапе скорее теоретических), связанных с субжем.
1. Каким образом внутренние сущности приложения (н-р, демона)
могут быть выставлены наружу в виде иерархии каталогов, для
общения с ним других приложений?
2. Можно ли реализовать озвученное в п. 1 посредством виртуальной
файловой системы?
3. Исходя из п.2: какие существуют ограничения на код, реализующий
файловую систему (что он может, к чему (каким системным сервисам)
может обращаться, что такому коду недоступно)?
4. Чисто в форме теоретического вопроса (вытекает из п. 3): можно ли
БД в СУБД представить в виде файловой системы и заставить ls/cd/vim
работать с этим монстром?
5. Существуют ли примеры/ссылки на примеры, реализующие подобный
подход композиции приложений?
Естественно, ответы на эти вопросы я погуглю и посмотрю в литературе.
Просто хотел обсудить их с опытными коллегами, может кто имел опыт в
этой области.
Здравствуйте, zaufi, Вы писали:
Z> если хочется из демона ӕкспортировать некую иерархию... Z> думаю придется покапать FUSE на предмет ее взаимодействия с Z> ядром и повторить ӕто в своем демоне
Спасибо! Посмотрю Fuse.
Вобщем виртуальные файловые системы выглядят красивым
способом организации общения приложений, как раз в рамках
идеологии Unix-Way. Конечно открыты вопросы быстродействия и
удобства реализации необходимых протоколов.
Прямо как чувствовали. На ЛОРе выложили ссылку на статью
.здесь
Re: ?Все есть файл.
От:
Аноним
Дата:
09.03.07 16:43
Оценка:
Здравствуйте, 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>> работать с этим монстром?
А> Можно, но зачем? Оверхед подобного подхода хорошо представляешь, да?
Конечно представляю. Ключевое сочетание здесь _Чисто_в_форме_теоретического_вопроса_.
Вобщем, спасибо! Понятно.
Re[3]: ?Все есть файл.
От:
Аноним
Дата:
14.03.07 10:11
Оценка:
Здравствуйте, wf, Вы писали:
wf>Здравствуйте, Аноним, Вы писали:
wf>>> 1. Каким образом внутренние сущности приложения (н-р, демона) wf>>> могут быть выставлены наружу в виде иерархии каталогов, для wf>>> общения с ним других приложений?
>> А зачем?
wf>Например, для того, чтобы работать с ними посредством большого количества wf>существующих приложений, используя традиционный для *nix подход на основе wf>"все есть файл".
Хорошо, расшифровываю вопрос. Модель данных какой предметной области хорошо представляется в виде файловой системы?
Вопрос без подвоха, на самом деле, мне самому интересно.
Здравствуйте, <Аноним>, Вы писали:
А>Хорошо, расшифровываю вопрос. Модель данных какой предметной области хорошо представляется в виде файловой системы?
Имхо что угодно. Но надо уметь остановиться вовремя.
Здравствуйте, Аноним, Вы писали:
А> Хорошо, расшифровываю вопрос. Модель данных какой предметной А> области хорошо представляется в виде файловой системы? А> Вопрос без подвоха, на самом деле, мне самому интересно.
Хм. Отвечаю не очень конкретно, так как практического
примера, где можно было бы прикрутить подобный метод
взаимодействия у меня нет — вопрос изначально носил
"теоретический" характер. Файловая система — иерархия. В виде
иерархии можно представить если и не все, то очень многое.
Не обязательно это именно модель данных предметной области.
Это могут быть внутренние структуры приложения,
обрабатывающего какие-либо данные: н-р, очереди, статистика
работы. Конечно понятно, что все это может располагаться в
файловой системе в виде реальных каталогов и файлов, а не
виртуальных, но это известный способ организации обмена.
Мне же было интересно как это же самое организовать посредством
виртуальной ФС.
Здравствуйте, 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>обрабатывающего какие-либо данные: н-р, очереди, статистика
Очереди для сервера тасующего туда-сюда данные (и не вдумывающегося в их смысл) -- вполне себе предметная область. Вопрос-то в другом.
Допустим, статистика каких-нибудь очередей или каналов данных. Как будем строить иерархию. По источнику? По приемнику? Городить что-то вроде
Здравствуйте, 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>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А?
Потому что была заменена более новым udev'ом, в котором можно конфигурировать наааааааамного больше всего, чем в devfs.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Здравствуйте, netch80, Вы писали:
N>>Хотя чем udev значительно лучше — мне не понять. ДД>Например, имена файлов устройств и права на них определяются в userspace.
Ну я на freebsd это могу и для devfs сделать. Средствами ядра (devfs, devfs.conf...) А чем userspace тут настолько лучше?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, netch80, Вы писали: N>>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А? C>Потому что была заменена более новым udev'ом, в котором можно конфигурировать наааааааамного больше всего, чем в devfs.
Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации. А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились?
Здравствуйте, netch80, Вы писали:
N>Ну я на freebsd это могу и для devfs сделать. Средствами ядра (devfs, devfs.conf...) А чем userspace тут настолько лучше?
Freebsd'шный devfs я не видел и не знаю, чем он отличается от linux'ового. Сравнение udev и devfs для linux см. здесь.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
Здравствуйте, netch80, Вы писали:
N>Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации.
Нет.
N>А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились?
А почитать про вопрос более подробно слабО?
В ядре неудобно и сложно делать кастомные политики именования и обработки событий. В udev созданием имен устройств занимаются обычные shell-скрипты, а в devfs политика именования зашита в код. Или ты предлагаешь пользователю заниматься перекомпилированием ядра и правкой ядерных исходников если ему не понравится система наименования устройств?
Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace.
Ну и вопрос надежности — в devfs примерно 90Кб ядерного кода, а в udev около 16. Чем меньше некритичного к скорости кода в ядре — тем лучше.
PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, netch80, Вы писали:
N>>Вопрос не в том. Я краем глаза видел обсуждение этой замены. Важным была не только конфигуряемость — это меньший вопрос. Большим вопросом было то, что было решено увести из ядра сложность реализации. C>Нет. N>>А вот почему — потому что "сложно"? Недостаточная причина. Наверно, не справились? C>А почитать про вопрос более подробно слабО?
А понять, что читал — слабО?:)) Из того факта, что я читал чьё-то мнение и комментарии, не значит, что я безусловно должен согласиться с оценками и выводами. Тем более, имея перед глазами примеры, которые как минимум показывают, что есть и другие пути (а как максимум — опровергают).
C>В ядре неудобно и сложно делать кастомные политики именования и обработки событий.
А живые примеры такой работающей политики как минимум на уровне назначения прав и разрешения видимости — наверно, мне приснились.
C> В udev созданием имен устройств занимаются обычные shell-скрипты, а в devfs политика именования зашита в код. Или ты предлагаешь пользователю заниматься перекомпилированием ядра и правкой ядерных исходников если ему не понравится система наименования устройств?
Вообще-то система _наименования_ устройств — та вещь, которую менять _очень_ стрёмно и лучше не разрешать её, даже если она в чём-то не нравится. Например, хотя бы потому, что те же имена выступают и в части внутренней диагностики, и при загрузке (`root=/dev/hda1'). И если кто-то вдруг решит, что ему нужен не hda1, а ad1s1... может, желание будет и понятное, но диверсионное.
А то что могла бы осмысленно делать devfs — контролировать выставление прав и доступы — на уровне ядра делается беспроблемно. Вот кусочек из фрёвого /etc/rc.d/named:
# Mount a devfs in the chroot directory if needed
#
umount ${named_chrootdir}/dev 2>/dev/null
devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
devfs -m ${named_chrootdir}/dev rule apply path null unhide
devfs -m ${named_chrootdir}/dev rule apply path random unhide
Соответственно в намедовом корне есть /dev/null и /dev/random, и ему достаточно.
А что делать, например, в single mode, когда udevd не может быть запущен, а админ играется с модулями? Вот он подгрузит scsi, а /dev/sda не появится. Пускать руками каждый раз синхронизатор? Запускать приблуду в фон?
C>Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace.
То есть причина именно в том, что одна конкретная реализация была неудобной?:))
C>Ну и вопрос надежности — в devfs примерно 90Кб ядерного кода, а в udev около 16. Чем меньше некритичного к скорости кода в ядре — тем лучше. C>PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev.
Так что — в нём возвращаемся к devfs?:)) И это после того, как расхвалили udev?
Здравствуйте, netch80, Вы писали:
C>>В ядре неудобно и сложно делать кастомные политики именования и обработки событий. N>А живые примеры такой работающей политики как минимум на уровне назначения прав и разрешения видимости — наверно, мне приснились.
Эээ... Как? Я не вижу никаких хуков для кастомизации в fs/devfs/base.c
Максимум что в devfs можно сделать — насоздавать симлинки.
N>Вообще-то система _наименования_ устройств — та вещь, которую менять _очень_ стрёмно и лучше не разрешать её, даже если она в чём-то не нравится. Например, хотя бы потому, что те же имена выступают и в части внутренней диагностики, и при загрузке (`root=/dev/hda1'). И если кто-то вдруг решит, что ему нужен не hda1, а ad1s1... может, желание будет и понятное, но диверсионное.
Не согласен.
Мне, например, жутко нравится ifrename. А еще кастомные политики могут быть полезны с устройствами из lvm или всяких NASов (Network Attached Storage).
Кроме того, в udev поддерживает персистентное именование. А то меня жутко раздражало — воткнешь USB-драйв в первый порт и у тебя будет /dev/sdc, а если воткнуть во второй порт — то уже /dev/sdd. Как ты предлагаешь такое решать в devfs? Создавать кучу симлинков — так и получим udev видом в профиль.
N>А то что могла бы осмысленно делать devfs — контролировать выставление прав и доступы — на уровне ядра делается беспроблемно. Вот кусочек из фрёвого /etc/rc.d/named: N>
N> # Mount a devfs in the chroot directory if needed
N> #
N> umount ${named_chrootdir}/dev 2>/dev/null
N> devfs_domount ${named_chrootdir}/dev devfsrules_hide_all
N> devfs -m ${named_chrootdir}/dev rule apply path null unhide
N> devfs -m ${named_chrootdir}/dev rule apply path random unhide
N>
N>Соответственно в намедовом корне есть /dev/null и /dev/random, и ему достаточно.
А откуда мы будем маски прав (или, не дай бог, POSIX ACLи) брать? Например, udev автоматически проставляет группу floppy для извлекаемых устройств.
N>А что делать, например, в single mode, когда udevd не может быть запущен, а админ играется с модулями? Вот он подгрузит scsi, а /dev/sda не появится. Пускать руками каждый раз синхронизатор? Запускать приблуду в фон?
В single-mode проще всего использовать статический /dev. Ну или что-то типа udevfs с минимумом без всяких наворотов.
C>>Далее, вопрос с событиями — нужно как-то передавать события о появлении/удалении устройств в userspace. В изначальном devfs это было сделано очень неудобно так что возникают race condition'ы — в udev это решается с помощью userspace-фреймоворка. Собственно, udev и начался с попытки добавить userspace-обработку событий к devfs, когда стало понятно, что проще все перенести в userspace. N>То есть причина именно в том, что одна конкретная реализация была неудобной?
Нет, они все будут неудобные. На LKML был флейм о порядке добавления устройств и об интересных race-condition'ах связаных с этим. Например, если поднятие одного устройства ведет к поднятию нескольких дочерних устройств.
C>>PS: сейчас делаю встроенное устройство, где использую udevfs (микро-devfs). Помогает уменьшить размер образа на несколько килобайт и позволяет не думать о каталоге /dev. N>Так что — в нём возвращаемся к devfs? И это после того, как расхвалили udev?
А мне полный devfs/udev не нужен, а достаточен udevfs, так как после запуска девайса в production на нем ничего больше меняться в железе не будет. А вот на десктоп такое я ставить не собираюсь.
Здравствуйте, netch80, Вы писали:
Q>>>>Так, а зачем виртуальная, если есть реальная. Замапил обычные файлы в память и все дела — все будет работать синхронно. N>>>Дададад. Исключительно синхронно. Вы притворяетесь или реально не понимаете, насколько сложные механизмы внутри ОС стоят за "простыми" операциями над FS? N>>>Или Вы собрались реализовывать преобразование состояния процесса в кусок реальной FS на лету, с апдейтом по каждому мелкому чиху? EK>>Хм. А что, дорожка "утиль -> fs -> fuse (или что там) -> демон" и выгребание состояния демона каким-то образом короче?
N>По крайней мере эффективнее (и значительно), если в демоне постоянно что-то происходит, а контроль или управление производится периодически по мере необходимости.
Ну, если иерархию держать большую и развесистую, то да. Однако исходно предлагалось замапить несколько файлов. Если читать реляционную базу данных через подобный интерфейс, то там естественно тормоза будут.
Q>>>> А то FUSE, VFS, драйвера. Не надо уподобляться MS и выдумывать проблемы на ровном месте. N>>>MS, говорите... Ну вот расскажите, безо всяких MS, почему в линуксе практически умерла devfs. А? EK>>Из за технических проблем. А разве нет?
N>А откуда эти проблемы возникли? Именно из-за того, что пытались на уровне VFS совместить работу с двумя источниками активности — внутренним (обновления устройств) и внешним (чтение/запись devfs из userland), и у них не получилось.
Честно говоря, я там код не смотрел, но почему именно здесь проблема? "Внешний" доступ из userland'а -- это, собственно, штатный способ доступа. "Внутренний" -- ну фиг знает, можно же было через ту же дверь ходить....
N>Хотя чем udev значительно лучше — мне не понять.
это концепт для понимания, а не для реализации. Анализ и Проектирование (то есть этапы до непосредственной реализации) — это этапы для того, чтобы выразить реальную потребность в математической модели. Естественно при создании этой модели использовать те кубики, которые лучше подходят по форме, а не те, которые самые красивые.
Так что если услышите, что "Сеть — это компьютер", не спешите встраивать в каждую программу сетевые возможности.
Для реализации Ваших задумок готового тулкита нет. Есть только API Fuse, на который Вам уже указали, но это довольно низкоуровневый кубик.
Если Вы заинтересованы в иерархическом представлении сервисов, то Файловая Система — не единственная такая возможность. Например, SNMP тоже даёт такое представление. Или большинство ORB-подобных вещей (тот же DBus, который уже очень популярен в современном Unix)
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
