Date: Fri, 28 Aug 1998 00:44:21 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: tlambert@primenet.com, mike@smith.net.au, tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PCI devices Message-ID: <199808280044.RAA03553@usr07.primenet.com> In-Reply-To: <199808271457.OAA00519@dingo.cdrom.com> from "Mike Smith" at Aug 27, 98 02:57:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > This is a fallacious conclusion. An OS which meets the criteria for > > > "PnP OS" in the preceeding discussion need not (and may not) work on a > > > system without a PnP BIOS. > > > > Then the OS sucks. > > Or perhaps it's just designed only to run on PnP systems. That's precisely the part that sucks. 8-p. > > 4) The PnP OS can then: > > > > A) issues the key sequence to put all PnP devices to > > sleep. > > B) identify all EISA, MCA, PCI, and PCMCIA hardware, for > > the purpose of excluding it from ISA identification. > > C) Identify all remaining (legacy) ISA hardware. > > It's arguably erroneous to perform this at this stage. It would be > more correct to attempt to locate *resources* claimed by such devices. Huh? How can it do this without locating the devices to which the resources are assigned? > > D) Perform PnP card isolation for configuration, and > > identify all possible locations for the cards. > > E) Perform closure over all possible configuration > > combinations for all cards. > > F) Configure the cards, as necessary. > > > > This is, in fact, the basis for the Microsoft claim that Windows 98 > > is better at autoconfiguration that most PnP BIOS's. In the presence > > of legacy cards unknown to the BIOS, Microsoft will not assign a > > resource used by a legacy card to a PnP card. > > Only if the operating system is capable of locating the device, and only > if the user has not correctly informed the BIOS of the resources > consumed by said device. If the user has behaved appropriately, the > information is available both to the BIOS and the operating system via > the ESCD data. Presuming the BIOS is willing to be informed (ie: that it is a PnP BIOS). If it's *not* a PnP BIOS, then it *won't* enable cards that come up disabled, and it *won't* do resource contention avoidance. > > Note that this will be necessary for the OS to do on non-Intel > > hardware in most cases, since the OS must run an x86 interpreter > > to implement the card POST and other BIOS execution functions > > for Intel cards in these systems. > > The number of ISA PnP adapters with onboard BIOS code is so low that > such emulation is virtually pointless. There is one specific case > (video adapters) which is already well covered on at least some > platforms (eg. the alpha console ROM contains an x86 emulator). The resource records are in the ROM, so the ROM has to be there. > > In any case, there should be no more reason for an OS to guess than > > there would be for a BIOS to guess. > > In the absence of ESCD information, the OS must guess as to the location > of system peripherals. It can only detect those peripherals that it > already knows about, ie. it must guess. In the presence of (correct) > ESCD information, the BIOS and the operating system both have the same > data, and modulo bugs in the BIOS implementation both can do the same > work. Unless the BIOS is not a PnP BIOS, in which case the OS has a much better shot. But since the OS can detect legacy hardware resource usage via probe, and the BIOS does not, the OS has an advantage, even in the PnP BIOS case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808280044.RAA03553>