Re: [PATCH] replace SYSV shared memory with shm filesystem

Richard Guenther
2000-01-11T11:18:11Z

Oh no! Not another /proc. Please do a different fs, perhaps you can
share some code with shmfs, but not the namespace!

Richard.

On 10 Jan 2000, James Antill wrote:
> > Andi Kleen <ak@muc.de> writes:
> > > On Mon, Jan 10, 2000 at 01:20:40PM +0100, Christoph Rohland wrote:
> > > > Hi folks,
> > > >
> > > > This patch implements a minimal filesystem for shared memory. It
> > > > replaces/reuses the existing SYSV shm code so you now have to mount
> > > > the fs to be able to use SYSV SHM. But in turn we now have everything
> > > > in place to implement posix shm. This also obsoletes vm_private_data
> > > > in vm_area_struct.
> > >
> > > I planed to map the Unix Sockets abstract name space to a file system
> > > for some time now. Because it would be silly to write another file
> > > system just for that rather obscure feature, would it be possible
> > > to use a subdirectory in your new shm filesystem? I haven't looked
> > > at the code at all yet, and don't know if it can even deal with
> > > directories and special devices. Do you have objections to such
> > > a direction?
> >
> > In the current state this is not possible. The shm fs does not support
> > directories and only regular files (which you can only mmap, no
> > read/write support).
> >
> > But we could later extend the fs to support directories and special
> > files. The Unix Sockets could probably also use the same mechanisms
> > for locating the special fs like SYSV ipc does.
> >
> > With these changes we also should then be able to mount the fs several
> > times. So we also get the chroot case fixed.
>
> If the idea is to integrate the unix domain sockets at some point,
> then I'd like to suggest that _both_ shm and unix domain sockets get a
> subtree. Ie.
>
> /kernfs/unix_domain_sockets/*
> /kernfs/sysv_shared_memory/*
>
> Instead of...
>
> /shm/unix_domain_sockets/*
> /shm/* (apart from unix_domain_sockets, and maybe others)
>
> Obviously example names might be too long for your tastes.
>
> This also makes it easier to add new directories (don't say it won't
> happen look at proc :).
>
> Indeed a possibly useful one that I can think of straight away is...
>
> /kernfs/users/<uid>/
>
> Where it could store entries to inodes that no longer have a file
> associated with them (Ie. like the proc/self/fd/* [1], but for each
> user).
>
> I'm not saying you should implement the fs above, just that it's
> going to hinder it (or anything like it) if you put shm in the root.
>
> --
> James Antill -- james@and.org
> I am always an optimist, but frankly there is no hope.
> -Hosni Mubarek
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.nl.linux.org/Linux-MM/