> > * 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 | [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
