From owner-freebsd-arch Wed Feb 5 5:45:11 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 0771B37B401 for ; Wed, 5 Feb 2003 05:45:10 -0800 (PST) Received: from HAL9000.homeunix.com (12-233-57-224.client.attbi.com [12.233.57.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2781E43F75 for ; Wed, 5 Feb 2003 05:45:09 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id h15Dj8mI000600; Wed, 5 Feb 2003 05:45:08 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id h15Dj8AA000599; Wed, 5 Feb 2003 05:45:08 -0800 (PST) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 5 Feb 2003 05:45:08 -0800 From: David Schultz To: Dag-Erling Smorgrav Cc: arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030205134508.GA520@HAL9000.homeunix.com> Mail-Followup-To: Dag-Erling Smorgrav , arch@FreeBSD.ORG References: <20030205045103.GB2168@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Dag-Erling Smorgrav : > David Schultz writes: > > BTW, it looks like the KASSERT in kalloc() eliminates the need for > > the one in malloc(). Furthermore, there's another KASSERT in > > malloc() that could be moved to kalloc(). > > I know. AT this stage, all the patch does is define the new API and > implement it in terms of the old one. I duplicated the KASSERT so I > could tailor the panic string to the new API. > > Note that since malloc() still exists and is not static, the patch > maintains binary compatibility (e.g. with modules compiled before the > patch was applied). It would therefore have been wrong to modify the > behaviour of malloc(). The check is conditional on INVARIANTS, and any module that can trigger the panic is broken and therefore incompatible with any valid ABI anyway. But I don't mean to nitpick; I thought I'd just point out the redundancy privately in case it was unintended. I would really like to see *any* reasonable fix for the malloc flags mess actually get committed, and your design certainly qualifies. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message