From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 18 02:37:22 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 99FB6106566B for ; Sat, 18 Feb 2012 02:37:22 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 697A68FC14 for ; Sat, 18 Feb 2012 02:37:22 +0000 (UTC) Received: by daec6 with SMTP id c6so4375795dae.13 for ; Fri, 17 Feb 2012 18:37:22 -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=NNTDmkqc9zKFobtXDs4eqpyDQElqyrvbzl99GQGkG8M=; b=anL0Wf6gisVbANOMJBJM2TNX49/jXlUBgQh0fZG4oRakgAHQ370RXieCxAIhrriBtA CZuGbiPz8yJTy4pQETSrV5H6+aU2V89+4v4Ag6D11Hzs6+D9z4J8u+DdfdynYtEYmzb8 auF2zkIwtobqcJ2y9ETt3/sAk59oECvu+W5ek= Received: by 10.68.216.195 with SMTP id os3mr24161066pbc.137.1329532641976; Fri, 17 Feb 2012 18:37:21 -0800 (PST) Received: from bakeneko.local ([74.195.19.178]) by mx.google.com with ESMTPS id kx17sm18234464pbb.19.2012.02.17.18.37.19 (version=SSLv3 cipher=OTHER); Fri, 17 Feb 2012 18:37:21 -0800 (PST) Message-ID: <4F3F0EA2.7010709@gmail.com> Date: Fri, 17 Feb 2012 18:36:18 -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: Julian Elischer 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> <4F3EF18F.5020301@freebsd.org> In-Reply-To: <4F3EF18F.5020301@freebsd.org> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=windows-1250 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 02:37:22 -0000 On 02/17/12 16:32, Julian Elischer wrote: >> On 02/17/12 14:08, rank1seeker@gmail.com wrote: >>>> For me as a user, that would be a much preferable approach, instille= d >>>> long ago by Linux. I don't like unused stuff around, and I like to >>>> understand what I am using. >>>> >>>> Some build kernel confutation parameters "minimum modules", "medium >>>> modules", "maximum modules" might be utilized. I would be using >>>> "medium" or most likely "maximum", leaving me with a minimal kernel.= >>>> >>>> -- Alex -- alex-goncharov@comcast.net -- >>> NO. >>> >>>> Thinking bigger picture (beyond sound), would it make sense to keep >>>> GENERIC very minimal, but provide an extensive loader.conf with a >>>> default install...so most things worked, but were loaded as modules?= >>>> >>>> Matt >>> NO. >>> >>> >>> You can't base a "wish" on a solution for YOURS problems! >>> >>> GENERIC must be as giantic as possible, to make as many machines as >>> possible to BOOT and enable all what can be enabled in/on them. >>> THEN ... individual "strips" unhooked parts -> custom kernel, via >>> wich you "specialize it", for your hardware! >>> >>> That is, unless individual is passive/bored (lazy?) and prefer >>> everything on a silver plate ... >>> There are many paths in that case ... >>> Windows are the easiest solution. THEY THINK FOR YOU! >>> ;) >>> >>> >>> Domagoj Smol=E8i=E6 >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to >>> "freebsd-hackers-unsubscribe@freebsd.org" >> I'm tired of Linux and "everything should be in the kernel, implemente= d >> 4 ways" approach. >> >> I think you misunderstood. GENERIC should be able to boot anything >> bootable within the architecture, right? We agree on that. Is sound >> required for booting? >> >> 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. >> >> However, as a compromise, if it must be in there, then put it in >> loader.conf and not the kernel. >> >> Do we still disagree? > > I think we probably should go two ways long and short term > 1/ generic is installed at boot > a) also install a truely "minimal" kernel and configure modules to > use with it. > but only once up and running with GENERIC. > 2/ in the logn term we should add teh ability to detect devices and > load modules > needed.. either from the loader, or in early boot. >> Matt >> >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "freebsd-hackers-unsubscribe@freebsd.org" >> >> > I really agree with 2 the most. 1 is true, and subsection a is manual as usual. I can recompile for that. I don't think anything *needs* to be done at all, and this really started on my part with a hypothetical. In the long run, though, option 2 is best. I certainly am not advocating removing tons of stuff from GENERIC, which is what people seem to hear in some cases. I'm advocating the KISS principle (Keep It Simple Stupid) and building a system out from there. Why lock in drivers not necessary to bring up a system? It's more danger (boot hangs, driver bugs, security vulnerabilities) for no benefit. If it's loaded as a module, there is the potential to prevent the load and continue on with boot or bring up the system. Sometimes that counts! Same goes for debugging, troubleshooting, trying to get poorly documented hardware to go through system S3 sleep...etc. Matt