From owner-freebsd-current Thu Oct 1 09:06:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13448 for freebsd-current-outgoing; Thu, 1 Oct 1998 09:06:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13408 for ; Thu, 1 Oct 1998 09:06:07 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id AAA18978; Fri, 2 Oct 1998 00:00:34 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810011600.AAA18978@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Poul-Henning Kamp , Garrett Wollman , Chuck Robey , current@FreeBSD.ORG Subject: Re: comment about verbose booting In-reply-to: Your message of "Thu, 01 Oct 1998 09:30:12 CST." <199810011530.JAA09811@mt.sri.com> Date: Fri, 02 Oct 1998 00:00:33 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams wrote: > > >> < > > dk> said: > > >> > > >> > If your're asking me, the identification of the VGA chips is > > >> > something which should be killed, it doesn't belong in the kernel. > > >> > > >> But we'll have ELF kernels soon enough, so theoretically we could put > > >> all of that stuff in its own section and then release the memory after > > >> boot. > > >> > > >> Isn't that what Terry is always flaming about? > > > > > >Don't joke... It's not all that difficult - > > > > But you miss the point: boot-time-only probing will soon be a thing > > of the past. > > Doubtful, w/out a *TON* of changes to the kernel. The current 'state of > the art' in FreeBSD is a long ways away from dynamic driver adding, and > my attempts to garner support were met with 'not in my kernel, thank you > very much'. I don't know how long ago this was, but things are changing pretty rapidly. We almost have the capability of doing some parts of this right now.. The main gotcha presently is internal kernel structure. The bus/device heirarchy mechanism that we got with the alpha code from Doug helps. The isa_devtab stuff sucks and must die. The main thing that seems to scare people (developers in particular) is the prospect of having a dozen or two object files that are loaded at boot time based on hardware. This is just one possibility folks. The things we're tinkering with at the moment allow for the possibility of having your cake and eating it too. You want a single image? Fine, grab the bits you want, do something along the lines of an 'ld -r -o kernel kernel.o nfs.o ufs.o if_de.o ...' etc and it'll just work. If on the other hand you rarely (or never) change things between releases, then it may suit you to have individual files and a configuration file that specifies what always gets linked in, and let the PCI and PnP stuff load the other drivers when there is corresponding hardware. This means you tell it to always load if_ed.o if you have a non-PnP isa card present. When (hopefully not "if") the boot-time probing mechanism is cleaned up so that it can run at any time (where it makes sense) with interrupts fully enabled, fully dynamic registration, etc, then things like pccard/cardbus/ scsi probing/etc become trivial to implement. And we'll be able to do all this without having to give up a single kernel image option. This is pie-in-the-sky stuff as yet and definately not a 3.0 item.. (but finshing kld and boot3 enough is on the 'trying really really hard' list) > Nate Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message