From owner-freebsd-arch Wed Jan 22 12:53:24 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 438B037B401 for ; Wed, 22 Jan 2003 12:53:23 -0800 (PST) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C10143F1E for ; Wed, 22 Jan 2003 12:53:22 -0800 (PST) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id h0MKswY77090; Wed, 22 Jan 2003 15:54:58 -0500 (EST) (envelope-from bmilekic@unixdaemons.com) Date: Wed, 22 Jan 2003 15:54:57 -0500 From: Bosko Milekic To: Sam Leffler Cc: "M. Warner Losh" , bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122155457.A77036@unixdaemons.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> <0aef01c2c23d$0f1ae690$52557f42@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0aef01c2c23d$0f1ae690$52557f42@errno.com>; from sam@errno.com on Wed, Jan 22, 2003 at 09:38:21AM -0800 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, Jan 22, 2003 at 09:38:21AM -0800, Sam Leffler wrote: > <...long discussion about default behaviours and how callers should not > require an M_* parameter when allocating an mbuf...> > > As one of the original authors of the mbuf code I must say that the intent > was for every call to specify whether or not to block waiting for more > memory. (I honestly can't recall if that is how the code worked, but that's > my recollection of how it was supposed to work). In general I consider it > very important that kernel code be as self-documenting as possible. As such > implicit states, modes, or actions are a bad idea. In this particular case > I want every call to clearly specify whether the caller is willing to block > or not. No default values. No implicit meanings (e.g. 0 gives you the > default behaviour). > > Separately I believe using a 0 value to mean "wait" was a mistake and one > that should be fixed. As has been discussed, to enforce this change and > catch old/broken code we need a mechanism to find instances. This is the > reason for changing the "wait" flag to be a non-zero value. I have a great amount of respect for your opinion on this matter and I am not religiously bound to doing it either way. However, I do think that leaving it as it is (with possibly defining M_WAIT{,OK} to 0 for KLD_MODULES) is the better thing to do. I realize that your idea of the interface is "it'll either block or not block," however when you think of the "new" approach don't think of it that way; rather, think of it as follows: "I am calling the allocator and it will do as much as it can to give me the resources I'm requesting (in the malloc() case, in fact, I'm sure it'll give me the resources I want or else block indefintely, in the mbuf allocator case it'll wait as long as I've configured it to wait - via a sysctl). I don't care what the allocator does. I am a thread executing in the kernel and let the allocator do whatever it takes to give me what I need." If you think of it that way you'll hopefully realize that it's no longer a question of whether or not to wait. Yes, we still provide a dontwait behavior, but in the new approach, that behavior is an _exception_, which is the way it should be. As I said, your thoughts are important to me (and I'm sure to anyone else involved in this discussion) but I have yet to read an argument as to why the dontwait case _shouldn't_ be treated like the exception that it is in SMPng. [...] > Sam Regards, -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message