Date: Wed, 10 Mar 2010 08:15:40 -0500 From: John Baldwin <jhb@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-7@freebsd.org Subject: Re: svn commit: r204931 - in stable/7/sys: amd64/include i386/include Message-ID: <201003100815.40537.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1003100025290.9081@fledge.watson.org> References: <201003092210.o29MABkU044256@svn.freebsd.org> <alpine.BSF.2.00.1003100025290.9081@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 09 March 2010 7:27:06 pm Robert Watson wrote: > > On Tue, 9 Mar 2010, John Baldwin wrote: > > > Log: > > MFC 183525: Bump MAXCPU to 32 now that 32 CPU x86 systems exist. > > Hmmm. I'd be a bit surprised if this doesn't cause ABI issues for > management/crashdump analysis tools, and KBI problems for kernel modules, > although it being 12:30am I'm having trouble thinking of specific instances > currently. That did occur to me. I could revert it. The public KBI for modules is that they should be using mp_maxid and not MAXCPU. Generally MAXCPU is only used for sizing static arrays for early boot before malloc() is available, and that code cannot be run from a KLD anyway (even kld's loaded via the loader don't start running SYSINITs until after SI_SUB_KLD). I think other uses of MAXCPU are most likely broken and that MAXCPU should not be part of the public KBI, but only for use in the kernel image itself. DPCPU in 8.0 makes this process even easier for modules that need per-CPU data relative to 7 perhaps. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003100815.40537.jhb>