From owner-freebsd-current Tue Jun 13 11:47: 9 2000 Delivered-To: freebsd-current@freebsd.org Received: from mass.cdrom.com (adsl-63-206-88-224.dsl.snfc21.pacbell.net [63.206.88.224]) by hub.freebsd.org (Postfix) with ESMTP id 5EB1237C04F; Tue, 13 Jun 2000 11:47:05 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA22933; Tue, 13 Jun 2000 11:51:04 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200006131851.LAA22933@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Luoqi Chen Cc: msmith@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: VMware detection code in boot loader In-reply-to: Your message of "Tue, 13 Jun 2000 13:53:39 EDT." <200006131753.e5DHrdi06492@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jun 2000 11:51:04 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > a larger issue. It is not the loader's job to detect the underlying > > > hardware configuration. > > > > Actually, in a broad fashion, it _is_. This is why the loader > > understands PCI and PnP, for example. > > > Why do we want to do that? Are we going to offload device probe routines to > the loader? I thought the loader only needs to understand bootable devices, > and it's the kernel's responsibility to handle the rest. It's hard to decide where to draw the line, and hard to decide what is or isn't part of the boot path. The simplest answer is just to have the loader load drivers for everything that it can find, which is the path that we've been walking down. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message