From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 11:24:14 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A03421065672; Sun, 12 Jun 2011 11:24:14 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 281238FC0A; Sun, 12 Jun 2011 11:24:13 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id p5CAEVRl009807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2011 12:14:31 +0200 Received: from [192.168.100.129] (206.Red-83-59-160.dynamicIP.rima-tde.net [83.59.160.206]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id p5CAEPrQ013722 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 12 Jun 2011 12:14:30 +0200 Message-ID: <4DF49181.1000007@entel.upc.edu> Date: Sun, 12 Jun 2011 12:14:25 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4DF3E98B.40108@FreeBSD.org> <20110612085649.GA11503@DataIX.net> In-Reply-To: <20110612085649.GA11503@DataIX.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sun, 12 Jun 2011 12:14:31 +0200 (CEST) Cc: jhell@DataIX.net, Doug Barton Subject: Re: rc.d script to load kernel modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 11:24:14 -0000 Al 12/06/11 10:56, En/na Jason Hellenthal ha escrit: > > umass for one I could see how it would speed up your boot since you > would not have to probe for USB devices to possibly mount root from but > not a big show stopper for those who don't need that so this would come > in handy in that case but could also be handled by devd more elequently. > > coretemp ichwd linux nvidia if_wpi: I can't really see how this would > speed up booting at all since the same initialization is going to be > done after root is mounted or before root is mounted. Whats the > difference here ? > > > Cutting modules out of the kernel in general does help speed up booting > but loading those same modules later in the boot process will just lead > you back to the same boot time. So all in all this would be just > subverting what loader.conf already does quite nicely... just loads. > I wouldn't say that. There are cases where kldloading modules from loader.conf take longer than kldloading them from rc.d scripts. For example, in my case, I'm booting from a zfs-only installation. Kldloading a ten or twelve modules in loader.conf takes a long time compared to a UFS-only installation. Moving them to a rc.d script would allow me to save a lot of time during the boot process. I do agree that it is dangerous to move certain modules like umass from loader.conf. For example, a NAS or pfsense installation would like to mount a umass device as the root filesystem. So I think this case is a little bit complicated. A brief messages explaining that umass needs to be kldloaded from loader.conf in the case of a usb as the root filesystem would be enough. So if we plan to have the possibility to do zfs-only installations in a near future (I think pcbsd people would love this) I think it is not a bad idea to move the kldloading of certain modules from loader.conf to the rc infrastructure. Best regards, Gustau