Date: Wed, 10 Jan 1996 20:03:59 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: smpatel@wam.umd.edu (Sujal Patel) Cc: terry@lambert.org, hasty@rah.star-gate.com, freebsd-hackers@FreeBSD.org Subject: Re: PnP Proposal, Ideas & Issues [Was: PnP problem...] Message-ID: <199601110303.UAA16329@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960110200018.9867B-100000@sl-015.sl.cybercomm.net> from "Sujal Patel" at Jan 10, 96 08:15:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. Right. You have to either succeed in probing everything that isn't PnP, or you have some amount of exposure. My suggestion is that the exposure be limited by allowing "pretend" devices to be added for non-disableable devices to make their resources "unmappable" for PnP devices. I really don't think there's much option otherwise. > 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). You can destructively (re)run the probe IFF you log so you can skip the destructive devices on subsequent restarts. > 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). Actually, the PnP manager gets loaded after the VWIN32 and VMM and sends a class of initialization events seperate from boot time events (SYS_DYNAMIC_DEVICE_INIT/SYS_DYNAMIC_DEVICE_EXIT). This is best described in the DDK in the PnP driver examples and in the DDK documentation (ddk/doc/pnp.doc). There is some discussion of the boot process in the book: Unauthorized Windows95 Andrew Schulman IDG Books ISBN 1-56884-169-8 $29.99 US $39.99 CA #28.99 UK > 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. Yup. That's the Registry. > 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). The sort is pretty easy. The manual configuration probably has to be there anyway to dummy up unprobed devices. As far as kernel bloat goes: we need pageable code for parts of the kernel. A lot of people hate this, arguing that kernel paging is bad... in which case, we should be keeping DOS loaded as part of our boot code instead of reclaiming the 640k. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601110303.UAA16329>