Date: Mon, 11 Sep 2000 12:36:41 -0700 From: Mike Smith <msmith@freebsd.org> To: mjacob@feral.com Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, arch@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Device probing... Message-ID: <200009111936.MAA14055@mass.osd.bsdi.com> In-Reply-To: Your message of "Mon, 11 Sep 2000 08:00:04 PDT." <Pine.BSF.4.21.0009110756150.69785-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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). Doing this on a PC is so problematic that the various PnP specifications that try to offload all of the resource management work onto the OS still talk about allocating resources for the "boot path". It's actually *extremely* difficult to do this, unless you have absolute knowledge of the mapping between "PROM device" and "kernel-space device". Consider the situation where you have initialised your disk driver, but want to use the "PROM driver" interface still to fetch another driver. Because (in the PC environment) you simply can't tell that the disk driver you've already initialised has taken over the hardware that the "PROM driver" path would use, you're stuck. In reality, this is less of an issue simply because most probing we do these days is entirely metainformation-based. How many of our probe routines actually do more than passive metainformation comparisons? > p.s.: FWIW, I'm *for* you doing this. I *hate* having to support polled mode > in drivers. I'm inclined to agree with this here. > 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. Most of the reasons for not doing this have gone away. We do need to re-order a few things though. Note that this will make it "interesting" if we want to support the interrupt hardware with "normal" drivers. > > 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 ? The biggest one that's left is that a lot of drivers will end up printing things in interrupt context, leading to *incredibly* messy console output. We'll need a cleaner way of presenting driver messages. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] 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?200009111936.MAA14055>