On Fri, Mar 22, 2002 at 01:48:35PM -0700, Jon Arney wrote: > Correct me if my interpretation of those links is incorrect. My > understanding of what you're shooting for is a translator free > implementation. i.e. You would like to see an implementation which > merely maps the shm* calls into existing filesystem calls.
Well, this is correc, except that all filesystems are translators :) We use the terms translator and filesystem almost synonymously. What we want to avoid if possible is creating an alternative interface where the filesystem and I/O interfaces are sufficient. > For instance, rather than having a shm_stat RPC, we might just > perform the mapping in libc. All details of how shared memory calls are mapped to filesystem calls will be put into glibc, thus on th eclient side, yes. We would not write a special filesystem for this (unless we must have extra RPCs), but we would use tmpfs rather than a disk based filesystem on the canonical place for performance. > Instead of a shm_statall RPC, we I am not familiar witht he shared memory interface, so I can not give you precise answer to the details. I should probably become familiar so I can review your suggestions. But maybe someone ese can help out in the meantime? > If this is the approach you're looking for, sysv message queues > and semaphores can use the same approach fairly easily. That's the idea. As much as possible should be done without adding new RPCs. It is very important that you spend some time working out the details of the design and verify that it really meets the desired specification (eg, if it is true that we can implement it with the normal filesystem RPCs and how to do it exactly). As Roland said, it is apparent that most of the stuff can be done using normal rpcs, but there might be some details which are not clear yet. Thanks, Marcus _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
