Date: Sun, 12 Jun 2011 10:20:16 +0800 From: Adrian Chadd <adrian@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: mdf@freebsd.org, "K. Macy" <kmacy@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <BANLkTi=h-LJAY3E0vTxdeMTVEj52D%2BJQcA@mail.gmail.com> In-Reply-To: <48A8C532-0972-49F8-BBA3-B0663E0D5067@bsdimp.com> References: <BANLkTin2AwKRT7N6HWqBctJcT72_mR=Otg@mail.gmail.com> <20110611171834.GA38142@zim.MIT.EDU> <BANLkTik=z-fb1sDwh0dr4hRWmdhLMWiKdw@mail.gmail.com> <20110611204326.GA51320@zim.MIT.EDU> <BANLkTino4eMNPQedE1TcxUYqgbuPNfhHKw@mail.gmail.com> <9349A935-F13D-4265-A59C-C1E9B35F2B73@bsdimp.com> <BANLkTi=wsPx8fyQz9wWwRLpMpv9esmawOQ@mail.gmail.com> <48A8C532-0972-49F8-BBA3-B0663E0D5067@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 June 2011 10:10, Warner Losh <imp@bsdimp.com> wrote: >>> Right now newbus uses Giant for all its locking. =A0That's the biggest = problem preventing parallel probe/attach. =A0Also, each and every bus calls= probe, then calls attach for each device in sequence. =A0Fixing that would= require changing all the bus drivers. >> >> >> Fair enough. That would only be worthwhile in the presence of a >> coordinated push to shorten boot / reset times. > > Agreed. =A0We could be a *LOT* faster if we stalled on first use rather t= han wait for all the stragglers. =A0No need to wait for network devices, or= that USB drive that's connected to the system until ifconfig or mount time= . =A0I think that has to be in the mix too. =A0But that dove-tails into som= ething like launchd where applications wait for the resources they use to f= inish initializing. How about first getting a modular GENERIC working for different platforms, with the relevant metadata to load in modules that are needed at loader time, or the relevant loader.conf snippet to emulate the GENERIC behaviour (and people can just comment out modules they don't need from that!). Then worry about why loading modules from loader takes so long (if it does, I've never benchmarked it!) Parallelising probe/attach where possible, which may be a good idea, seems like an orthogonal problem. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=h-LJAY3E0vTxdeMTVEj52D%2BJQcA>