From owner-freebsd-arch Mon Sep 11 8: 0:32 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 34C2B37B423; Mon, 11 Sep 2000 08:00:27 -0700 (PDT) Received: from beppo.feral.com (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id IAA10432; Mon, 11 Sep 2000 08:00:27 -0700 Date: Mon, 11 Sep 2000 08:00:04 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... In-Reply-To: <89354.968526601@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 The only theoretical problem with this is if you ever want to do a BOOT driver based autoload mechanism. Currently FreeBSD has the ability to load (preload) modules. If, in the future, you want to load modules after loading a primary kernel object but before configuring your root device's bus and driver stack, you need to do callbacks to a PROM driver. It's even harder to do this if you've enabled interrupts (or even changed MMU mappings, btw). So- if there's any chance you want to ever do a load as you go model, having interrupts enabled might make it more difficult. -matt p.s.: FWIW, I'm *for* you doing this. I *hate* having to support polled mode in drivers. On Sat, 9 Sep 2000, Poul-Henning Kamp wrote: > > I would really like to se us move all the device probe/attach code > to run in "normal context", ie enable interrupts before we probe > everything. > > The main argument for this is the drivers can then use the full > complement of kernel infrastructure and interrupts during probe > attach. > > Drivers needs to be able to function in this environment anyway > if they support removeable devices (pccard, usb, etc). > > Are there reasons to not do this I have overlooked ? > > -- > 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-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message