From owner-cvs-src@FreeBSD.ORG Tue Jan 16 10:23:20 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1587A16A415; Tue, 16 Jan 2007 10:23:20 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 96B3613C441; Tue, 16 Jan 2007 10:23:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 530D046F7A; Tue, 16 Jan 2007 05:23:17 -0500 (EST) Date: Tue, 16 Jan 2007 10:23:17 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randall Stewart In-Reply-To: <45ABD171.1050509@cisco.com> Message-ID: <20070116101754.G52843@fledge.watson.org> References: <200701151506.l0FF6S6D022659@repoman.freebsd.org> <200701151933.39686.max@love2party.net> <45ABD171.1050509@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Max Laier , 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 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 10:23:20 -0000 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