Date: Wed, 5 Feb 2003 05:45:08 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Dag-Erling Smorgrav <des@ofug.org> Cc: arch@FreeBSD.ORG Subject: Re: New kernel allocation API Message-ID: <20030205134508.GA520@HAL9000.homeunix.com> In-Reply-To: <xzpznpbq8qe.fsf@flood.ping.uio.no> References: <xzp8ywvs6yu.fsf@flood.ping.uio.no> <xzp65rzs6ry.fsf@flood.ping.uio.no> <20030205045103.GB2168@HAL9000.homeunix.com> <xzpznpbq8qe.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Dag-Erling Smorgrav <des@ofug.org>: > 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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030205134508.GA520>