From owner-freebsd-audit Sat Jul 14 16:17:37 2001 Delivered-To: freebsd-audit@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 8CFA437B405; Sat, 14 Jul 2001 16:17:32 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f6ENHQS91614; Sat, 14 Jul 2001 16:17:26 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 14 Jul 2001 16:17:13 -0700 (PDT) From: Matthew Jacob Reply-To: To: John Baldwin Cc: Alfred Perlstein , , Subject: Re: planned change to mbinit code and minor changes to mp startu In-Reply-To: Message-ID: <20010714161650.K29535-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >> /* > > > > This should be in some file where other "per cpu" systems can get at it, > > duplicating it everywhere is gross. (for instance, my cpu affinity > > patches). > > Agreed. sys/pcpu.h is one possibility. > > > Also, since it looks like this would break if we suddently started > > up another CPU I really don't agree with not populating the pools > > if 'CPU_ABSENT(i)'. > > Well, I think what we will want in that case is to have the equivalent of cpu > attach/detach routines that also have a list of handlers that other subsystems > can register to be called when a CPU is added/removed. For example, the mbuf > system would add handlers to allocate and teardown the per-CPU counters. > yes, that's probably right. What shall we do for the short term? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message