Re: System V Shared Memory

[Jon Arney]

Neal,

Thanks for doing the cleanup.  I'll try to study your changes and
improve
next time.  I'll concede that there was probably a logic error or two
in there and I didn't throw any mutexes in for thread safety.  My fault.

The file 'list.h' comes from the Linux source and I like to use it
becuase it encapsulates linked list functionality in a pretty efficient
manner. Only after the fact did I realize it had an unclean pedigree.

I have a couple of questions on your implementation, however, that I
just
don't understand.  You commented out the entire 'IPC_SET' case from the
shmctl function.  I'm not clear on why you did this.  How else can we
enforce permissions on shared memory segments?  I'm not sure why you
object to using __file_chown() to do this.  I would think that using 
chown/chmod would be better than nothing, but what do I know.

Secondly, why is it not acceptable to use hurd rpc's in glibc?
I did think about it for a while and concluded that I _should_ use
the hurd RPCs after looking at things like 'rmdir.c' which directly
call hurd RPCs.  Perhaps I'm missing the point somewhere.

> It does not do cuig, cgid, shm_cpid, shm_lpid or shm_nattach which is
> needed by the IPC_STAT function of shmctl.  I think that we need to
> talk about the proper way to support this.  I considered reserving the
> first vm_page_size of each file, however, we cannot be sure that all
> users can write to the file -- they may only be permitted to read it.
> As for overloading other fields, there just are not enough to go
> around.

I ran into this as well and had exactly the same thoughts you did.  The
only thing that I could think to do was to provide an additional RPC
at the filesystem to provide these functions.  That was _sort-of_
the intent with 'chauthor' in that perhaps we create a new RPC
for these things specific to SHM and make it so that if the RPCs
are not implemented, we don't fail hard, we just don't provide all the
data.  That way, we could use SHM on normal filesystems but not get
all of the accounting information on them.

The problem only gets worse with the other SYSV-IPC functions.  The
shared memory functions seem to be the easiest to implement when
it comes to statistics reporting.  Even if it were possible to get
by with overloading fields for shm, it definitely is not possible
for semaphores and message queues.

The problem with putting the data in another file or in the file
itself is that it will be nearly impossible to ensure that no-one
can come along behind you and corrupt it, remove it, etc.

Thanks,

-Jon.