Date: Wed, 05 Feb 2003 15:55:46 +0100 From: phk@freebsd.org To: Dag-Erling Smorgrav <des@ofug.org> Cc: David Schultz <dschultz@uclink.Berkeley.EDU>, arch@freebsd.org Subject: Re: New kernel allocation API Message-ID: <40415.1044456946@critter.freebsd.dk> In-Reply-To: Your message of "Wed, 05 Feb 2003 12:15:21 %2B0100." <xzpznpbq8qe.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <xzpznpbq8qe.fsf@flood.ping.uio.no>, Dag-Erling Smorgrav writes: >David Schultz <dschultz@uclink.Berkeley.EDU> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40415.1044456946>