Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!decwrl!access.usask.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: terry@cs.weber.edu's message of Tue, 30 Mar 93 00: 36:56 GMT Message-ID: <DERAADT.93Apr10131342@newt.fsa.ca> Sender: news@fsa.ca Nntp-Posting-Host: newt.fsa.ca Organization: little lizard city References: <DERAADT.93Mar11154207@newt.fsa.ca> <1993Mar15.223046.10278@fcom.cc.utah.edu> <DERAADT.93Mar25200858@newt.fsa.ca> <1993Mar30.003656.2601@fcom.cc.utah.edu> Date: Sat, 10 Apr 1993 20:13:42 GMT Lines: 41 In article <1993Mar30.003656.2601@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: Soloution 2 depends on modifying every device driver to include a "shutdown" routine. This is necessary anyway for taking the UART's out of FIFO mode when using Chris' new com drivers, since the BIOS initialization routine is too stupid to initialize the hardware from *any* potential state to a known state; again, since the reset is done by the main processor and not the bus as a result of it's architecture, this can't be done in a com-card specific fashion, and thus can not be directly supported in the BIOS reset code anyway (an ISA deficiency). The second soloution has a failure mode in the event of a panic, since a panic does not constitute a normal soft-shutdown. The second soloution, or something like it, will be necessary to support the unloading of loadable drivers in future versions of 386BSD in any case, since we can not rely on a soft or hard reset in the event of a reload of a previously loaded driver. Solution 2 does something which should have been done already by the probe/attach routines. Those two routines are responsible to, no matter what happens, initialize the device in question into a known state. Obviously, we can say that the current weprobe()/weattach() routines do not do that. There is no reason to have a shutdown routine, if probe()/attach() had enough brains in them to be able to initialize to a known state. It seems stupid to me change the established bsd technique and add yet another function, which really should be done by probe()/attach(). If my machine crashes, the "shutdown" function won't be called, then upon reboot it _still_ won't find the card. This is a fantastically losing proposition. Indeed.. resetting devices when you take the machine down so that they'll be in a "good state" when you reboot -- this is IDIOCY. probe() and attach() are enough: probe() can mess the device up as much as it wants to find out if it really exists, attach() must take the device from any random state to a known state. That's not currently happening in a LOT of device drivers. Again... go look at a vax device driver to see how careful those guys were.. -- This space not left unintentionally unblank. deraadt@fsa.ca