Re: Shared-Memory for the Hurd?

[Farid Hajji]

Thanks for your commments. They helped greatly clarify some ideas!

>      So, how does one do non-io operations?  The function
>      file_name_lookup (/include/hurd.h) returns a file_t which happens
>      to be a perfectly valid port that any type of message can be sent
>      to (not just io messages; of course, unknown messages will fail,
>      however, you get the point).
This is what I had in mind. So I'll try to send the task control port
directly to this file_t and see if the translator task gets it. I don't
know yet if the message will be grokked by mach itself (mach inserts
the port right transparently in the receiver's task) or if some special
handling needs to be done.

>      To conclude, the shm server would live in, e.g. /servers/shm.
>      Inheriting from libtreefs or libdiskfs seems like a good idea
>      (enabling you to expose the maps in that directory).  Using trivfs
>      is a bad idea (I did it in my procfs:
>      ftp://walfield.org/pub/people/neal/hurd/procfs; don't worry, it
>      will not be going in CVS).
libtreefs was what I had in mind for the "fullsized" shm-translator.
About libdiskfs, I'm not sure yet (read: I must read more sources yet).
Basically, I don't need a filesystem-backend (say ext2, ufs, ...),
just a tree (directory) structure to hold, say /servers/shm/0,
/servers/shm/1, ... libdiskfs would be useful for a memory-based
filesystem, which is not exactly what I have in mind. But again
I'll have to read more about libdiskfs before.

>   *  Getting a task's task port would likely have to be done by
>      requesting it from the task itself  (Correct me if I am wrong,
>      however, I do not think that it can be requested from anyone except
>      the task itself; check /include/hurd/process_request.defs).
>      However, shmat, for instance, is wrapped in a libc function, then
>      this would be quite transparent.
Sure, the shmat()/shmget() caller will have to provide this port itself
one way or the other. The easiest way will be for shmget() to send the
result of mach_task_port() to the file_t of the shm-translator. Having
the translator ask for the task port of its clients (e.g. pid2task())
is not so good.

>   *  Servers normally use many demuxers.  That is to say that they may
>      implement their own interface and use others from libraries are the
>      same time.  For instance:
[snip]
Good examples! That will help too.

Now I must first figure out how to use libtreefs/libdiskfs by
writing a translator with dummy callbacks. If I get there, the
rest will be much more easier.

Thanks,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.