From: "Christoph Rohland" <cr@sap.com>
To: "'Stas Sergeev'" <stsp@aknet.ru>
Cc: "'Hugh Dickins'" <hugh@veritas.com>, "'Andrew Morton'" <akpm@osdl.org>,
       <linux-kernel@vger.kernel.org>
Subject: RE: [patch][rfc] expandable anonymous shared mappings
Date: Mon, 28 Jun 2004 16:25:19 +0200
Message-ID: <AC444F6A32413E438EAD09097B39E3DE7B4D10@dewdfe10.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
In-Reply-To: <40D9CFAC.9040609@aknet.ru>
Importance: Normal
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1077
Lines: 32

Hi Stas,

> But no, my prog won't die without the expandable
> anon shared mapping thing. I can resort to the other
> matters. I can (as I do right now) to just open a
> tmp file in /dev/shm and use the custom allocator.

BTW that's what librt does: look into /dev/shm scheck if it is tmpfs and do
an open...

> Yes, that works, but I wanted to keep it "simple
> and stupid". The anon shared mapping looked like
> the good candidate to try out.

Yes, I understand. For your use case anon shared mem with the small addition
is perfect.

> And then I thought it may be nice if the kernel
> to provide this functionality. 

For me the question is: The functionality you propose is very specific for
your problem. The kernel should provide general solutions. So is there a
bigger demand for this?

Greetings
                  Christoph

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/