Date: Tue, 12 Sep 2000 08:21:29 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@FreeBSD.ORG> Cc: smp@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: system initialization order. Message-ID: <Pine.BSF.4.21.0009120816450.71155-100000@beppo.feral.com> In-Reply-To: <78946.968769061@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009120816450.71155-100000>