From owner-freebsd-arch Wed Jan 22 9:38:26 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 682DE37B401 for ; Wed, 22 Jan 2003 09:38:25 -0800 (PST) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id D74EC43EB2 for ; Wed, 22 Jan 2003 09:38:24 -0800 (PST) (envelope-from sam@errno.com) Received: from melange (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.5/8.12.1) with ESMTP id h0MHcLnN079733 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 22 Jan 2003 09:38:21 -0800 (PST)?g (envelope-from sam@errno.com)œ X-Authentication-Warning: ebb.errno.com: Host melange.errno.com [66.127.85.82] claimed to be melange Message-ID: <0aef01c2c23d$0f1ae690$52557f42@errno.com> From: "Sam Leffler" To: "Bosko Milekic" , "M. Warner Losh" Cc: , References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com> Subject: Re: M_ flags summary. Date: Wed, 22 Jan 2003 09:38:21 -0800 Organization: Errno Consulting MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 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 <...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. As to binary compatibility, I was under the impression that we'd already decided that 5.0 did not mark the start of an ABI freeze because there were too many issues still to be decided (e.g. Robert's MAC->m_tag changes). As such I considered the M_WAIT redefinition fair game and a good move. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message