Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!saimiri.primate.wisc.edu!caen!destroyer!cs.ubc.ca!unixg.ubc.ca!kakwa.ucs.ualberta.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!xenlink!fsa.ca!deraadt From: deraadt@fsa.ca (Theo de Raadt) Subject: Re: my bug list In-Reply-To: deraadt@fsa.ca's message of Fri, 26 Mar 1993 03: 08:58 GMT Message-ID: <DERAADT.93Mar25202827@newt.fsa.ca> Sender: news@fsa.ca Nntp-Posting-Host: newt.fsa.ca Organization: little lizard city References: <1993Feb27.235240.7476@coe.montana.edu> <1mpdb0INNo8a@ftp.UU.NET> <DERAADT.93Mar11154207@newt.fsa.ca> <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca> Date: Fri, 26 Mar 1993 03:28:27 GMT Lines: 52 In article <DERAADT.93Mar25200858@newt.fsa.ca> deraadt@fsa.ca (Theo de Raadt) writes: > terry@cs.weber.edu (A Wizard of Earth C) writes: > >I think you'll find that the majority of the problem here is the PC bus > >architecture being device-indeterminate. THere is no mechanism whereby I > >can ask a device "what are you?". This is distictly different from most > >of the bus architectures out there today (like VME/BI/QBUS/FutureBus/SBUS/ > >etc.). > > This has absolutely diddly squat to do with a hardware inventory. VMEbus > on a Sun does not have a hardware inventory list either. Somehow it > works just fine in sun3 and sun4 machines, eh? To follow up a bit more.. The vax does not supply a hardware inventory list either. The entire information as to where devices can be found is the config file. It is of course legal in the config file to do something like this.. device we0 at isa? port ? net irq ? iomem ? iosiz ? vector weintr assuming of course that the weprobe() routine was able to figure out all the rest. Terry -- you DON'T need a hardware inventory list to be able to do this! The probe routine could have a list of possible sequences of places to *try* to find the device. About a month ago I suggested a simpler change. I wanted simply that the "irq" value could be entered as "?" and the device driver's probe() routine could find the IRQ. isa/isa.c already checks for IRQ collisions... Unfortunately I've had very poor luck with making the changes because whoever wrote the original ISA IRQ code in 386BSD seemed to know next to nothing about how to the BSD probing code works. At least that person could have read the papers that describe it <hmph!>, and they'd have found out that greater flexibility is required. Interrupts should be enabled during config time, so that you can see if you really found the device! The BSD method for finding devices is... cause an interrupt from the device to CHECK if it really exists. Now, all the devices which people are having trouble with CAN cause an interrupt. But interrupts are fully disabled while booting! The code that needs rewriting is in isa/isa.c gets rewritten, in case anyone who knows more about the ISA bus wants to venture in and make it work so interrupts are fully enabled while the probe routines are being run. (Look at the vax code to see how it's supposed to be written.) It's amazing how much "Not Invented Here Syndrome" is happening here.. <tdr. -- This space not left unintentionally unblank. deraadt@fsa.ca