From owner-freebsd-hackers Wed Jan 10 17:22:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA18440 for hackers-outgoing; Wed, 10 Jan 1996 17:22:47 -0800 (PST) Received: from sl-015.sl.cybercomm.net (sl-015.sl.cybercomm.net [199.171.196.143]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA18428 for ; Wed, 10 Jan 1996 17:22:34 -0800 (PST) Received: from sl-015.sl.cybercomm.net (localhost [127.0.0.1]) by sl-015.sl.cybercomm.net (8.6.12/8.6.12) with SMTP id UAA10635; Wed, 10 Jan 1996 20:15:44 -0500 Date: Wed, 10 Jan 1996 20:15:44 -0500 (EST) From: Sujal Patel X-Sender: smpatel@sl-015.sl.cybercomm.net To: Terry Lambert cc: hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.org Subject: Re: PnP Proposal, Ideas & Issues [Was: PnP problem...] In-Reply-To: <199601102135.OAA15484@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org Precedence: bulk On Wed, 10 Jan 1996, Terry Lambert wrote: > This is probably a bad approach. The idea of PnP is that the devices > will fit into an unused space. This is a difficult (and potentially > insoluable without a hack job) problem for non-PnP ISA devices in a > standard ISA bus, since if you can't probe them, you can't predict > what the conflicts would be. The main problem for me to implement PnP devices like they were "intended" is that there is no easy way that I can figure out, to get a reliable list of resources that are used at boot time. The ISA device structure, for example, lists I/O base addresses but doesn't say how many ports the device is going to use. Also, devices like uha0 and bt0 are EISA devices on the isa0 controller-- These devices auto-probe their IRQ at boot time, so there is no easy way to find out their IRQ. Now consider the more complicated case of a Installation Floppy. The only way to implement "true" PnP is to: 1- Probe PCI devices 2- Probe EISA devices 3- Probe PC-CARD devices 4- Reset PnP devices so they don't get probed in the ISA probe 5- Probe ISA devices 6- Find all of the PnP devices, configure each one using a topological sort [Time to dig up that old Knuth book :)], Assign a driver to each card using the list of devices that Microsoft provides, and then re-run the ISA Probe... Can you just run the ISA probe twice?? Or is this sequence even practical? My feeling is that it isn't practical and manual configuration of PnP devices is the cleanest way to do it (for now). Even Win95 (I hate to use it as an example, but it's the only PnP-capable OS that I can think of) seems to configure PnP cards before the boot sequence. That's why when you add a PnP card you get "New Hardware added" or something like that. In Win95, you get the choice of the configuring PnP cards before you reboot (similar to a kernel configuration file). The only difference between my implementation and Win95's is that Win95 will give you a "suggested" configuration for a PnP device (by using some kind of fitting scheme like a topological sort)... This sort of thing would actually be pretty simple to implement since after the boot sequence is done, you have a fairly good idea of what resources are in use and which ones aren't (though it's still quite fuzzy). If FreeBSD were to turn all Win95-ish, you could implement a scheme to fit all the PnP cards into your setup automatically and write out a kernel configuration; and this is sort of how Win95 handles it now. Why bloat the kernel up with topological sorts and auto-configuration code. I'm trying to adhere to "Keep is simple!"-- A simple manual configuration in the kernel config (and adding PnP support to the boot-time kernel configurer), should be good enough (and really the only practical way I can see right now). Sujal