From owner-freebsd-arch  Wed Feb  5 10:58:25 2003
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5B5DE37B401; Wed,  5 Feb 2003 10:58:23 -0800 (PST)
Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 9BA4B43F43; Wed,  5 Feb 2003 10:58:22 -0800 (PST)
	(envelope-from tlambert2@mindspring.com)
Received: from pool0205.cvx21-bradley.dialup.earthlink.net ([209.179.192.205] helo=mindspring.com)
	by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128)
	(Exim 3.33 #1)
	id 18gUkX-0002GI-00; Wed, 05 Feb 2003 10:58:22 -0800
Message-ID: <3E415E7B.25C1D42@mindspring.com>
Date: Wed, 05 Feb 2003 10:56:59 -0800
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: phk@freebsd.org
Cc: Dag-Erling Smorgrav <des@ofug.org>,
	David Schultz <dschultz@uclink.Berkeley.EDU>, arch@freebsd.org
Subject: Re: New kernel allocation API
References: <40415.1044456946@critter.freebsd.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a435b63c88da451e6dfc662e062ebe0d55350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-arch.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-arch>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-arch>
X-Loop: FreeBSD.ORG

phk@freebsd.org wrote:
> If we are going to implement a new kernel allocator API, there are
> a host of issues we should consider, Jeff already mentioned one of
> them, passing size to ::free, and we must also design the API so that
> we can implement debugging and correctness checks in an efficient
> and usable manner.

For someone who uses C++ scope identification in the listing of the
function name "free", your support of knowing the size of the object
being freed is mystifying.  If the size of the object is passed in
to the free function, it means that it can't be freed by a function
which destructs a superclass.  E.g.:

	struct superclass {
		...
	};
	struct class1 {			/* 1024 bytes */
		struct superclass c1_sc;
		...
	};
	struct class2 {			/* 512 bytes */
		struct superclass c2_sc;
		...
	}

	struct superclass *
	zifmeac1()
	{
		struct class1 *c1p;
		c2p = malloc(sizeof *c1p);
		...
		return((struct superclass *)c1p);
	}

	struct superclass *
	zifmeac2()
	{
		struct class2 *c2p;
		c2p = malloc(sizeof *c2p);
		...
		return((struct superclass *)c2p);
	}

	main()
	{
		struct superclass *sc;
		...
		if( condition)
			sc = zifmeac1();
		else
			sc = zifmeac2();
		...
		free( sc);
	}

> Considering the problems our kernel suffers from at the moment,
> inventing a new memory allocation API is not even on the top 50
> list of things we need to do.
> 
> So can we just shelve this proposal until we have time and need for
> it and until we know (even) more about the needs of our SMPng kernel ?

You mean like "the ability to deprecate blocking allocations
incrementally, by changing which API is used"?  That's what DES's
patch provides.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message