Date: Wed, 22 Jan 2003 12:30:08 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Daniel Eischen <eischen@pcnet1.pcnet.com> Cc: arch@FreeBSD.ORG, bright@mu.org, "M. Warner Losh" <imp@bsdimp.com>, Bosko Milekic <bmilekic@unixdaemons.com> Subject: Re: M_ flags summary. Message-ID: <XFMail.20030122123008.jhb@FreeBSD.org> In-Reply-To: <Pine.GSO.4.10.10301221211510.29028-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Jan-2003 Daniel Eischen wrote: > 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 <bmilekic@unixdaemons.com> 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. I originally didn't like this change either because I viewed M_WAITOK and M_NOWAIT as different types rather than treating NOWAIT as a flag. Now that I've adopted the latter view (just as M_ZERO, etc. are flags) I'm probably in favor of just leaving things as they are. The manner in which such an API was proposed and swiftly implemented w/o review leaves much to be desired, but I prefer the new API to the old one now. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20030122123008.jhb>