Date: Tue, 16 Jan 2007 10:23:17 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Randall Stewart <rrs@cisco.com> Cc: Max Laier <max@love2party.net>, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_subr.c src/sys/sys systm.h src/share/man/man9 Makefile hashinit.9 Message-ID: <20070116101754.G52843@fledge.watson.org> In-Reply-To: <45ABD171.1050509@cisco.com> References: <200701151506.l0FF6S6D022659@repoman.freebsd.org> <200701151933.39686.max@love2party.net> <45ABD171.1050509@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 15 Jan 2007, Randall Stewart wrote: >> and why are we useing new flags, btw? Can't we just pass down the normal >> malloc flags? I seem to remember that we do that in a couple of places >> already. > > Well... I was game to either method.. I think the general thought was that > there may be OTHER non-memory flags that we direct at hash-init someday.. > and having them not locked to memory was a good thing.. > > Robert might care to comment on this one .. of course it can always be > changed to be just the memory flags too :-) Yes -- this is exactly what I have in mind. Today, the flags simply indicate memory allocation disposition, but I think it's reasonable to assume that like several other complex object allocators/initializers, we might want additional flags in the future. I think I prefer the sf_buf_alloc() model (custom flags mapped as needed into underlying operations), rather than the soalloc() model (reuse some but not all memory flags). Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070116101754.G52843>