Date: Tue, 30 Oct 2007 13:31:25 -0400
From: Rik van Riel <riel@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Marcelo Tosatti <marcelo@kvack.org>, linux-kernel@vger.kernel.org,
       drepper@redhat.com
Subject: Re: OOM notifications
Message-ID: <20071030133125.3458420c@cuia.boston.redhat.com>
In-Reply-To: <20071030155525.GF9702@duck.suse.cz>
References: <20071018201531.GA5938@dmt>
	<20071030145720.GB27039@atrey.karlin.mff.cuni.cz>
	<20071030112346.4b48bfe5@cuia.boston.redhat.com>
	<20071030155525.GF9702@duck.suse.cz>
Organization: Red Hat, Inc
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 999
Lines: 25

On Tue, 30 Oct 2007 16:55:25 +0100
Jan Kara <jack@suse.cz> wrote:

>   Hmm, that's right, but still the kernel->userspace interface could be via
> netlink (which is much more flexible than signals etc.) and then in userspace
> we could implement also some simple interface (UNIX socket?) for server like
> apps...

I think we all agree that it should not be a Unix signal, if only
because glibc cannot manipulate memory pools from signal handlers :)

The low memory message (for lack of a better word) needs to get to
userspace over a file descriptor, which the process can select() or
poll() on from its main loop.

Whether that is a device node, a sysfs file, a netlink socket or
something else ... I don't particularly care :)

-- 
All Rights Reversed
-
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/