Date: Sun, 12 Jun 2011 01:51:00 +0200 From: "K. Macy" <kmacy@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: mdf@freebsd.org, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <BANLkTi=wsPx8fyQz9wWwRLpMpv9esmawOQ@mail.gmail.com> In-Reply-To: <9349A935-F13D-4265-A59C-C1E9B35F2B73@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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. > > Right now newbus uses Giant for all its locking. =A0That's the biggest pr= oblem preventing parallel probe/attach. =A0Also, each and every bus calls p= robe, then calls attach for each device in sequence. =A0Fixing that would r= equire changing all the bus drivers. Fair enough. That would only be worthwhile in the presence of a coordinated push to shorten boot / reset times. Thanks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=wsPx8fyQz9wWwRLpMpv9esmawOQ>