From owner-freebsd-arch@FreeBSD.ORG Sun Jun 12 02:15:15 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7D5C106566B; Sun, 12 Jun 2011 02:15:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9C28FC12; Sun, 12 Jun 2011 02:15:15 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p5C2BLQb058589 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 11 Jun 2011 20:11:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 11 Jun 2011 20:10:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <48A8C532-0972-49F8-BBA3-B0663E0D5067@bsdimp.com> References: <20110611171834.GA38142@zim.MIT.EDU> <20110611204326.GA51320@zim.MIT.EDU> <9349A935-F13D-4265-A59C-C1E9B35F2B73@bsdimp.com> To: "K. Macy" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 11 Jun 2011 20:11:21 -0600 (MDT) Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 02:15:15 -0000 On Jun 11, 2011, at 5:51 PM, K. Macy wrote: >>> Although I imagine that many drivers silently benefit from being >>> loaded serially, to the best of my knowledge there is nothing >>> architecturally requiring this apart from the fact that the = scheduler >>> isn't started until everything else tied to initialization happens. >>> The absence of any sort of preemption was a bit of a thorn in my = side >>> back when I was working on "xenbus", as the linux implementation >>> relies on the use of multiple thread contexts. I don't know how much >>> effort to date has been put in to making boot fast. >>=20 >> Right now newbus uses Giant for all its locking. That's the biggest = problem preventing parallel probe/attach. Also, each and every bus = calls probe, then calls attach for each device in sequence. Fixing that = would require changing all the bus drivers. >=20 >=20 > Fair enough. That would only be worthwhile in the presence of a > coordinated push to shorten boot / reset times. Agreed. We could be a *LOT* faster if we stalled on first use rather = than wait for all the stragglers. No need to wait for network devices, = or that USB drive that's connected to the system until ifconfig or mount = time. I think that has to be in the mix too. But that dove-tails into = something like launchd where applications wait for the resources they = use to finish initializing. Warner=