Date: Wed, 22 Jan 2003 15:54:57 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Sam Leffler <sam@errno.com> Cc: "M. Warner Losh" <imp@bsdimp.com>, bright@mu.org, arch@FreeBSD.ORG Subject: Re: M_ flags summary. Message-ID: <20030122155457.A77036@unixdaemons.com> In-Reply-To: <0aef01c2c23d$0f1ae690$52557f42@errno.com>; from sam@errno.com on Wed, Jan 22, 2003 at 09:38:21AM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030122155457.A77036>