From owner-freebsd-arch Tue Sep 12 8:21:55 2000 Delivered-To: freebsd-arch@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 9491037B424; Tue, 12 Sep 2000 08:21:49 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA15455; Tue, 12 Sep 2000 08:21:49 -0700 Date: Tue, 12 Sep 2000 08:21:29 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. In-Reply-To: <78946.968769061@critter> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > With SMPng I think we need to take a good hard stare at the > order in which we initialize the system, a lot of the reasons > behind the current order are invalid, and some new reasons for > a new order are not honoured. > > Roughly speaking, I think we need something like this order: > > init console You can't init a real console w/o h/w. This has been the awful grotesque ugliness of the at least the alpha NetBSD && FreeBSD ports. Despite what Mike said in a different context, I have to say you will init a console early- using some kind of boot or throwaway driver- possibly even just a buffer to store output, until the real console can be initialized after, in *proper* order, the h/w for the real console is there. > print copyright > initialize VM/malloc(9) > init other stuff needed for: > setup proc0 > setup proc1 (park it on a semaphore for now) > setup idle procs > enable scheduler > init hardclock > enable hardclock interrupt > initialize timecounters > Fine, fine... > This should now represent a sufficiently "normal" environment that > the order of the rest doesn't really matter very much: > > init network protocols > init pseudodrivers In some cases pseudo drivers depend on real drivers, don't they? > probe/attach real drivers > > ata/scsi delayed probing needs thought about here. Yes. SCSI/FC more than ATA. Some thought might be given to avoiding complete evaluation here and doing what Solaris does instead which would allow you to parse a boot path and try and guess which specific device you need to get initialized. You don't to wait for 200 disks to probe if you can help it. > > locate & mount root > let proc1 loose > > Comments ? > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message