Date: Mon, 13 Feb 2012 07:29:28 -0800 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: Volodymyr Kostyrko <c.kworr@gmail.com> Cc: Alexander Leidinger <Alexander@Leidinger.net>, stable@FreeBSD.org Subject: Re: Reducing the need to compile a custom kernel Message-ID: <20120213152928.GA74772@icarus.home.lan> In-Reply-To: <4F3926C5.3010403@gmail.com> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210231059.GA25777@icarus.home.lan> <4F3926C5.3010403@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote: > Jeremy Chadwick wrote: > >I want to note here: the pf ALTQ options are a pain in the butt, quite > >honestly. I've found in the past that removing the ones you don't use > >won't result in a successful build, thus one must include them all. We > >do need ALTQ support though, for rate-limiting capability. The NOPCC > >option is needed for SMP builds, which makes me wonder what the state of > >SMP is in this regard -- meaning, on non-SMP builds, is it still safe > >to include ALTQ_NOPCC? > > It seems like I'm missing something. What is good about using > non-SMP kernel? Nothing. It's a question of whether or not use of ALTQ_NOPCC causes breakage on non-SMP kernels, or if FreeBSD even bothers to support non-SMP at this point. "Non-SMP" means "without options SMP". Rephrased: if SMP is the default, and "options SMP" works just fine on systems without multiple processors/cores, then the ALTQ_NOPCC option should probably be removed. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120213152928.GA74772>