From owner-freebsd-arch Wed Feb 5 6:55:50 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 9F55D37B401 for ; Wed, 5 Feb 2003 06:55:49 -0800 (PST) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 642DC43FA7 for ; Wed, 5 Feb 2003 06:55:48 -0800 (PST) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id h15EtkYu040416; Wed, 5 Feb 2003 15:55:46 +0100 (CET) (envelope-from phk@freebsd.org) To: Dag-Erling Smorgrav Cc: David Schultz , arch@freebsd.org Subject: Re: New kernel allocation API From: phk@freebsd.org In-Reply-To: Your message of "Wed, 05 Feb 2003 12:15:21 +0100." Date: Wed, 05 Feb 2003 15:55:46 +0100 Message-ID: <40415.1044456946@critter.freebsd.dk> 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 In message , Dag-Erling Smorgrav writes: >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. 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. 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 ? Thanks in advance. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message