From owner-freebsd-arch Wed Jan 22 9:21: 3 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 F23ED37B401 for ; Wed, 22 Jan 2003 09:21:01 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59D4D43EB2 for ; Wed, 22 Jan 2003 09:21:01 -0800 (PST) (envelope-from eischen@pcnet1.pcnet.com) Received: from localhost (eischen@localhost) by mail.pcnet.com (8.12.3/8.12.1) with ESMTP id h0MHKjdr000240; Wed, 22 Jan 2003 12:20:45 -0500 (EST) Date: Wed, 22 Jan 2003 12:20:45 -0500 (EST) From: Daniel Eischen To: Bosko Milekic Cc: "M. Warner Losh" , bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. In-Reply-To: <20030122100253.A76397@unixdaemons.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 22 Jan 2003, Bosko Milekic wrote: > On Tue, Jan 21, 2003 at 10:20:25PM -0700, M. Warner Losh wrote: > > In message: <20030121224148.A75236@unixdaemons.com> > > Bosko Milekic writes: > > : I think that defining M_TRYWAIT and M_WAITOK to 0 for KLD_MODULES is > > : fine but I do not think that defining them to anything other than 0 is > > : fine just so that we could add that KASSERT() that Warren suggested in > > : the allocation code. As you point out, defining it to anything other > > : than 0 would actually break ABI compatibility. Defining it to 0 for > > : KLD_MODULES would preserve both API and ABI compatibility for those > > : who actually care. Certainly, both M_TRYWAIT and M_WAITOK would have > > : to be defined in order to maintain full backwards-API compatibility. > > > > Actually, I think that we shouldn't define them to be 0 for modules. > > Instead, we should define them to the new values. However, we should > > accpet '0' with the old meaning for a while (maybe with a printf). > > There are going to be enough ABI changes between 5.0 and 5.branch that > > worrying about this one is likely not worth the effort to do special > > things for the modules. It isn't going to be too much longer before > > it becomes impossible for 5.0-RELEASE compiled modules to not operate > > with 5.0-CURRENT. [ Good summary elided ] Bosko convinces me. One other thing. How about adding another version of malloc that _only_ acts as if M_NOWAIT was specified and disallow M_NOWAIT from the original malloc()? If flags confusion is a problem, then provide versions of malloc() that don't have flags as arguments, or perhaps don't allow M_WAITOK or M_NOWAIT. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message