Date: Wed, 10 Jan 1996 20:13:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: smpatel@wam.umd.edu (Sujal Patel) Cc: gibbs@freefall.freebsd.org, neil@synthcom.com, terry@lambert.org, hasty@rah.star-gate.com, freebsd-hackers@freebsd.org Subject: Re: PnP problem... Message-ID: <199601110313.UAA16389@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.960110211637.9867H-100000@sl-015.sl.cybercomm.net> from "Sujal Patel" at Jan 10, 96 09:22:30 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The listing is not complete, but you get the idea. You should keep this > > in mind while doing your PnP work since I think this is the approach > > we should be shooting for. > > I have been keeping this in mind while I was coding. To change over to > a scheme that you described would be very simple. Right now, I just > gather the PnP configuration information from the kernel configuration; > this would simply change to information from PCI/EISA/ISA probes, after > the ISA code was cleaned up. > > A couple of quick questions: Is there a unified structure where one can > access the information from PCI/EISA/ISA probes? How well can the ISA > code non-invasively probe devices (currently)? Well, for the second question, the answer is "it depends on the device being probed". 8-(. This is why Win95 uses the arbitrary "if it takes too long, reset your machine..." and logging: to allow destructive probes to explode. 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?199601110313.UAA16389>