Date: Wed, 22 Jan 2003 09:38:21 -0800 From: "Sam Leffler" <sam@errno.com> To: "Bosko Milekic" <bmilekic@unixdaemons.com>, "M. Warner Losh" <imp@bsdimp.com> Cc: <bright@mu.org>, <arch@FreeBSD.ORG> Subject: Re: M_ flags summary. Message-ID: <0aef01c2c23d$0f1ae690$52557f42@errno.com> References: <20030122023246.GP42333@elvis.mu.org> <20030121224148.A75236@unixdaemons.com> <20030121.222025.101592442.imp@bsdimp.com> <20030122100253.A76397@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<...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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0aef01c2c23d$0f1ae690$52557f42>