| 1 |
Mike Edenfield wrote: |
| 2 |
|
| 3 |
> Just for reference, 9p is not Plan 9, it's only the Plan 9 network |
| 4 |
> protocol/distributed file system, which you can use on Linux with the |
| 5 |
> appropriate file system modules. |
| 6 |
|
| 7 |
Right. Either you use the kernel module (which now is in mainline |
| 8 |
for quite a long time), or 9pfuse, or one of the userland libraries |
| 9 |
around (eg. libmvfs). |
| 10 |
|
| 11 |
The basic idea behind this all is to use a filesystem as a primary |
| 12 |
IPC interface. Files dont necessarily mean things stored on-disk, |
| 13 |
but streams/communication-channels in an hierachical namespace. |
| 14 |
(eg. /proc or /sys). |
| 15 |
|
| 16 |
This way you have a very simple IPC mechanism using the very same |
| 17 |
semantics as filesystems do traditionally. That's just consequently |
| 18 |
using the "everything's a file"-metaphor. As everything's a file, |
| 19 |
all an OS or an distributed environment has to provide is dispatching |
| 20 |
filesystem operations from client to server, whereever they may |
| 21 |
actually reside. For example, you can simply mount any Plan9 device |
| 22 |
via 9P, from anywhere, as long as you get some 9P path there. |
| 23 |
|
| 24 |
|
| 25 |
(BTW: 9P doesnt have the concept of ioctl()s. If some object has |
| 26 |
more than just a single IO stream, it's modeled as an directory, |
| 27 |
eg. containing some "ctl" file accepting additional commands, etc). |
| 28 |
|
| 29 |
|
| 30 |
cu |
| 31 |
-- |
| 32 |
---------------------------------------------------------------------- |
| 33 |
Enrico Weigelt, metux IT service -- http://www.metux.de/ |
| 34 |
|
| 35 |
cellphone: +49 174 7066481 email: info@×××××.de skype: nekrad666 |
| 36 |
---------------------------------------------------------------------- |
| 37 |
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme |
| 38 |
---------------------------------------------------------------------- |
Archives