Re: Shared-Memory for the Hurd?

[Farid Hajji]

> >   * each shm-segment is represented by a pseudo-file managed by a
> >     fullsized translator settrans on e.g. /shm. The translator manages
> >     vm_allocate()ed pages just like in 3.) and 4.), mapping them to
> >     the pseudo-files [that is: shm-segment 34343 is mapped to /shm/34343].
> 
> Yes, this is a way to go. This could be a derivative of tmpfs, providing
> only a flat directory (Roland suggested /var/run/sysvshm) and only accepts
> certain file names coresponding to a key_t != 0 "with a funny behaviour
> about unlinking open files so the SHM_RMID behaviour is right." (Roland).
> 
> Farid, this is an excellent medium sized project to dive into the Hurd
> inners. Are you still interested in implementing this?
Yes, sure. Though I'm currently extremely busy with an urgent project
and I will not have the time to start this Right Now (tm) ;-).

> > Notes:
> >   * shm-segments are visible as plain [pseudo-] files and could also
> >     be mmap()-ed, or read()/write()... from other processes that have
> >     enough permissions.
> 
> Yes, mmap() would be ideal.
Agreed.

> > 5. same as in 4, but much more harder to implement, since there
> >    is no good template/hello for a full filesystem translator in
> >    the Hurd right now (besides full-blown ext2, ufs).
> >    -> What about /procfs translator? Someone wrote such a beast,
> >       but it is not in CVS. Where to get it please?
> 
> Well, tmpfs should be a good start. It isn't functional currently and not
> tested, but there are only small changes necessary to make it work (coming
> soon). tmpfs uses virtual memory to store the files.
Yes, the source of diskfs-based tmpfs looks intersting (I didn't test it yet).

As such, tmpfs could be extended/modified, by adding an RPC (or a family of
RPCs?), which would loosely match the shm*() functions:

  requesting task                RPC message            shm-server

     shmget(CREATE, ...) ----> open(O_CREAT) --------> create shm-segment
     shmget(OPEN, ...)   ----> open(O_RDWR, ...)-----> verify credentials
     shmat(somewhere)    ----> attach(task_control()-> vm_map()
     shmdt()             ----> detach(task_control()-> vm_unmap()
     shmctl(DELETE)      ----> unlink() -------------> destroy shm-segment

Note that most RPCs are just simple file operations (like create, open,
unlink, ...) which are already handled by diskfs. The new RPCs that need
to be caught by a multiplexer are attach() and detach(), which will pass
the task control port of the requester to the shm-server. The shm-server
would then vm_map() and vm_unmap() the [parts of] the virtual memory
corresponding to the shm-segments into the address space of the requester
tasks. Would this make sense?

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.