From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 13:09:45 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B770D1065673 for ; Tue, 14 Feb 2012 13:09:45 +0000 (UTC) (envelope-from matheus@eternamente.info) Received: from phoenix.eternamente.info (phoenix.eternamente.info [109.169.62.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5DDFD8FC27 for ; Tue, 14 Feb 2012 13:09:45 +0000 (UTC) Received: by phoenix.eternamente.info (Postfix, from userid 80) id 640911CC6F; Tue, 14 Feb 2012 09:49:56 -0300 (BRT) Received: from 187.114.198.119 (SquirrelMail authenticated user matheus) by eternamente.info with HTTP; Tue, 14 Feb 2012 10:49:56 -0200 Message-ID: <57e2e07a4c574f537aab522ea9fa33aa.squirrel@eternamente.info> In-Reply-To: <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120210144449.GA2358@psconsult.nl> <20120214113120.Horde.7fNzdpjmRSRPOjf4S1XjmXA@webmail.leidinger.net> Date: Tue, 14 Feb 2012 10:49:56 -0200 From: "Nenhum_de_Nos" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Reducing the need to compile a custom kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:09:45 -0000 On Tue, February 14, 2012 08:31, Alexander Leidinger wrote: > Quoting Paul Schenkeveld (from Fri, 10 Feb 2012 > 15:44:50 +0100): > >> On Fri, Feb 10, 2012 at 02:56:04PM +0100, Alexander Leidinger wrote: >>> Hi, >>> >>> during some big discussions in the last monts on various lists, one of >>> the problems was that some people would like to use freebsd-update but >>> can't as they are using a custom kernel. With all the kernel modules >>> we provide, the need for a custom kernel should be small, but on the >>> other hand, we do not provide a small kernel-skeleton where you can >>> load just the modules you need. >>> >>> This should be easy to change. As a first step I took the generic >>> kernel and removed all devices which are available as modules, e.g. >>> the USB section consists now only of the USB_DEBUG option (so that the >>> module is build like with the current generic kernel). I also removed >>> some storage drivers which are not available as a module. The >>> rationale is, that I can not remove CAM from the kernel config if I >>> let those drivers inside (if those drivers are important enough, >>> someone will probably fix the problem and add the missing pieces to >>> generate a module). >>> >>> Such a kernel would cover situations where people compile their own >>> kernel because they want to get rid of some unused kernel code (and >>> maybe even need the memory this frees up). >>> >>> The question is, is this enough? Or asked differently, why are you >>> compiling a custom kernel in a production environment (so I rule out >>> debug options zhich are not enabled in GENERIC)? Are there options >>> which you add which you can not add as a module (SW_WATCHDOG comes to >>> my mind)? If yes, which ones and how important are they for you? >> >> - INET without INET6 >> - SOFTUPDATES, UFS_ACL, AUDIT, SCTP (left out for embedded devices) >> - Björn may add INET6 without INET >> - SCHED_ULE vs. SCHED_4BSD >> - No vga console/atkbd/psm for embedded devices >> - CPU_SOEKRIS, CPU_GEODE, CPU_ELAN, NO_SWAPPING for embedded devices > > Embedded devices are out of the scope of this, normally you do a lot > of other modifictions to such systems anyway, so a custom kernel > should be not a big problem. > > I will also not touch the dual-stack part of the kernel config (it > shall still allow the generic purpose computing like the GERNERIC > config). I'm really curious why, if they are the piece of hardware that usually are worse to compile things on, for access issues to poor hardware (great to compile kernel+world on i7, pain to do so in my net5501-70). its a bummer to hear this :( matheus >> - IPSTEALTH, IPSEC, IPSEC_FILTERTUNNEL, IPFILTER, ALTQ for firewalls > > Request noted. > >> I also always specify exactly one CPU type (on i386), know it made a >> difference in the 386/486/586 era but am not sure how much difference >> it makes nowadays. > > The 386 part (which we do not have anymore in GENERIC) made a > difference, the rest doesn't hurt in the kernel. > > Bye, > Alexander. > > -- > Smuggling... It's not just a job, it's an adventure! > -- paid for by your local Colombian recruiting office > > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style