Re: Linux style /proc filesystem translator

[Marcus Brinkmann]

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