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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
