From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 03:22:49 2012 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21788106564A for ; Sat, 18 Feb 2012 03:22:49 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E562F8FC16 for ; Sat, 18 Feb 2012 03:22:48 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so4934251pbc.13 for ; Fri, 17 Feb 2012 19:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=xZ7Mgfa3/XsxOqQWcGIKTAeNPQYbps3CmYKVJYvxNLc=; b=i4pdjE57vIUcljflkIO+40LsKQCgY49Wi3gnrmyl0OvHh3vXzD/Qsjz3AeO0TKD34l DMvDHSWLxIDdLaYpK4q676rxgWyT4qAOkfDvBarO4gvQuMu52z4mOCZvroyvvlJ/yJTr XKl+ZadWW6DCUVZV1IiTnLxKMdCy/5cF2p+fE= Received: by 10.68.243.197 with SMTP id xa5mr30151048pbc.68.1329535368637; Fri, 17 Feb 2012 19:22:48 -0800 (PST) Received: from bakeneko.local ([74.195.19.178]) by mx.google.com with ESMTPS id 7sm18334489pbw.13.2012.02.17.19.22.45 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 19:22:46 -0800 (PST) Message-ID: <4F3F1948.1080206@gmail.com> Date: Fri, 17 Feb 2012 19:21:44 -0800 From: matt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120111 Thunderbird/9.0 MIME-Version: 1.0 To: Doug Barton References: <4F3E8225.9030501@FreeBSD.org> <4F3E8C26.3080900@FreeBSD.org> <4F3EA5F2.9070804@gmail.com> <4F3EAE5F.6070903@gmail.com> <20120217.220802.988.2@DOMY-PC> <4F3EDEBC.7040703@gmail.com> <4F3EFB70.5000102@FreeBSD.org> In-Reply-To: <4F3EFB70.5000102@FreeBSD.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rank1seeker@gmail.com, hackers@freebsd.org Subject: Re: 8 to 9: Kernel modularization -- did it change? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 03:22:49 -0000 On 02/17/12 17:14, Doug Barton wrote: > On 02/17/2012 15:11, matt wrote: >> We have a modular kernel. It makes best-practices-sense to keep the >> kernel true to what's required to boot and initialize the hardware >> required to come up multiuser. I am actually against having sound in >> there at all. > I think the question is not, "What should be in the kernel?" but rather= > "What should be on by default?" *How* those things are provided is a > different question. > > One could argue that an intelligent installer combined with a more > modular kernel would be the right answer. > >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. > I keep hoping that if I repeat this enough times that people will get > the word. :) Because loading modules through loader.conf is > veeeeeerrrrryyyyyy sssssllllloooooowwwwww I added an rc.d script called= > kld that will load the specified modules after disks are mounted. This > is at least an order of magnitude faster. Look for kld_list in > rc.conf(5) if you want the details, but the short version is that you > just do something like, kld_list=3D"umass coretemp ichwd linux nvidia".= > This is in all the -stable branches (including 7), is already in 9.0, > and will be in 8.3. > > Obviously you have to have everything in kernel and/or loader.conf > that's necessary to get your local disks available, and the system to > the point where it can start running rc. But everything else can go in > kld_list. > > > hth, > > Doug > Imagine: 1.You've just completed the install 2.Dialog comes up, "Would you like to have FreeBSD detect unloaded drivers and load them at next startup?" YES/NO 3.Reboot 4.If YES: detect unattached drivers like sound, firmware req'd wireless etc, coretemp/amdtemp, smb/iic, wireless?, acpi_ibm/asus/etc and store in kld_list rc variable 5.continue booting 6. If YES: last, one-time RC script. "FreeBSD booted successfully with the autodetected modules. Make changes permanent? YES/NO 7. If YES store kld_list, if NO clear it (or remove additions :) 8. first login In the example, you could just choose NO and manually compile your lean, mean FreeBSD kernel. That would be the power user choice. Choosing YES would be perfect for people just starting FreeBSD for the first time, for machine images intended to be cloned and for live-cd/PXE applications. In other words, you could choose YES and shutdown, capturing the image right before autodetect. If you had driver problems, you could boot single and change the rc.conf kld_list. If there was a security problem with a sound driver, it might not have even been loaded. If there was a suspend issue, etc...kldunload works, and yet the driver may as well be in the kernel. This way you can get GENERIC to be bloated in disk, network, usb, pci, etc drivers needed to boot, and you can use modules for peripherals, sensors, and non-boot essential hardwares. Best of both worlds, I think...well it's a hypothetical, but I look forward to the next round of flames, it's been educational :). Matt