another needed kernel addition

Ulrich Drepper (drepper@ipd.info.uni-karlsruhe.de)
10 Aug 1997 02:01:17 +0200


Hi,

I've another feature I miss in the current kernel and this is perhaps
related to all these recent filesystem changes.

Many of the objects which can be created using POSIX.1 functions have
to be in a global namespace, they must have real filenames (+ paths
eventually). As an example take shm_open().

This function takes a name and returns a special descriptor for this.
Other processes using the same name must get a descriptor for the very
same object unless it was unlinked before.

The descriptor must not be a normal file descriptor. In fact, the
only file operations allowed on this descriptors are `ftruncate' and
`close'. Additionally shared memory objects can be mapped using
`mmap' (how else should they be read from or written to :-).

>From my amateurs view of the system I could imagine a generic
implementation which can also be used by the other global objexts we
need to define (such as memory queues or semaphores).

Would it be possible to implement for each of these object types a new
filesystem? Since it is allowed that these objects are allowed to
appear in the normal filesystem tree one could mount them somewhere in
/proc.

The problems I see:

- shm_open ("/foo/bar/baz", ...)

must be possible even though there will never be directories /foo and
/foo/bar created. Those directories should be created and removed
automatically.

(The object could be visible as /proc/shm/foo/bar/baz with the current
size. Access permissions have no meaning.)

- Is it possible to restrict the legal actions on these objects on
ftruncate, close, mmap, and munmap (perhaps mremap)? Does the
implemented jumptable mechanism allow this?

If the VFS implementation could handle this I think all the different
object types could be handled. The special FSes simply define a
special kind of "file" and since this functionality is not always
needed (at least for the first time) they can easily be put in a
kernel modules. The libc could map

shm_open ("/foo/bar/baz", O_RDWR)
to
open ("/proc/shm/foo/bar/baz", O_RDWR)

and this would automatically trigger the loading of the module (if
this is some kind to automatic mounting).

Could people who understand something about all these VFS stuff
comment on it, correct the suggestion and implement it?

(Oh, this functionality cannot be implemented on top the the SysV shm
mechanisms.)

-- Uli
---------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------