Subject: Re: Increasing SHMMAXPGS
To: None <kpneal@pobox.com>
From: Olaf Seibert <rhialto@polderland.nl>
List: tech-kern
Date: 07/08/2002 01:20:31
On Sun 07 Jul 2002 at 17:52:08 -0400, kpneal@pobox.com wrote:
> On Sun, Jul 07, 2002 at 10:18:06AM -0700, Chuck Silvers wrote:
> > since SHM segments actually do have names and they exist independently
> > of mappings in any process, I'll argue that they're really more like
> > files than anonymous memory.  SHM segments also have owners, permissions
> > timestamps, etc.  the SHM namespace is basically a virtual-memory-backed
> > file system with a flat namespace, so it would really make more sense
> > to think of it like a file system.
> 
> Off the cuff thought: If the SHM namespace is basically a file system
> then how come there is no real filesystem interface for it? IE, why
> use a special tool to get a list of segments when ls could do the trick?

I had a very similar thought: why not put these shared memory segements
in some real directory in a real file system, and then just implement
access via mmap()? If one wants to remove an unused shared segment, just
rm the file?

<speculation mode="wild">

To make that possible, I was even thinking of incrementing the link
count of a file for each used mapping, but that would be inconsistent
with normal mmap() and file system behaviour. Or perhaps a symlink which
indicates which process has the file mapped. That would somehow also be
convenient for normal mmap()ped files... Perhaps this could be useful in
the /proc file system. Or this can be generalised even further to just
all files that a process has open.

</speculation>

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert - rhialto@       -- Woe betide the one who feels
\X/ polderland.nl  -- remorse without sin - Tom Poes, "Het boze oog", 4444.