From owner-freebsd-hackers@FreeBSD.ORG  Mon Sep 29 17:04:07 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 7E21616A4BF
	for <freebsd-hackers@freebsd.org>;
	Mon, 29 Sep 2003 17:04:07 -0700 (PDT)
Received: from web10509.mail.yahoo.com (web10509.mail.yahoo.com
	[216.136.130.192])
	by mx1.FreeBSD.org (Postfix) with SMTP id D7A1C4400F
	for <freebsd-hackers@freebsd.org>;
	Mon, 29 Sep 2003 17:04:05 -0700 (PDT)
	(envelope-from b_oshea@yahoo.com)
Message-ID: <20030930000405.12154.qmail@web10509.mail.yahoo.com>
Received: from [156.153.254.42] by web10509.mail.yahoo.com via HTTP;
	Mon, 29 Sep 2003 17:04:05 PDT
Date: Mon, 29 Sep 2003 17:04:05 -0700 (PDT)
From: Brian O'Shea <b_oshea@yahoo.com>
To: Peter Pentchev <roam@ringlet.net>,
	Pawel Jakub Dawidek <nick@garage.freebsd.pl>
In-Reply-To: <20030929155613.GB551@straylight.oblivion.bg>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: freebsd-hackers@freebsd.org
cc: earthman <earthman@inbox.ru>
Subject: Re: user malloc from kernel
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Sep 2003 00:04:07 -0000

--- Peter Pentchev <roam@ringlet.net> wrote:
> > Here you got sample kernel module which do this:
> > 
> > 	http://garage.freebsd.pl/usmalloc.tgz
> > 	http://garage.freebsd.pl/usmalloc.README
> 
> Errrr... but won't this interfere *badly* with userland programs
> which attempt to allocate memory after making the syscall in question?

Couldn't the user library interface to this new system call just
malloc() the memory first in the process, and then pass the pointer
and size to the kernel via the system call interface?  This would
ensure that malloc() doesn't touch the desired range of memory until
it is freed by the user.  You'd just have to be careful not to free
it until the kernel is done with it.

-brian


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com