Date: Mon, 25 Oct 1999 21:56:05 -0600 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@mt.sri.com, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910260356.VAA17204@mt.sri.com> In-Reply-To: <199910260221.TAA26021@usr06.primenet.com> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I think that a driver that crashes the system as a result of > the hardware being ejected is arguably a broken driver, from > the standpoint of complying with the Windows removable device > driver writers guide. Not true. The design simply does not take into account the fact that certain hardware/software interactions can not be coded in such a way to always recognize that the hardware is gone. The PCMCIA/PCCARD hardware/software specification did not take into account some very important design considerations. > I don't think that you can point at a particular failing instance, > and then generalize from that about how it's supposed to work (as > opposed to how it does work). My whole argument was based upon the reading of the specification and knowledge of hardware/software. My failing instance is to rebut your argument that 'just because it works on my box, it must therefore work'. It's broken by design, and although I can minimize the problems in software, there are still going to be races inherent in the design. The mostly working suspend/resume code in FreeBSD is *my* attempt to minimize those races, but stating that those races don't exist is foolish. I worked hard (and got lost of good help from Bruce) to make the window small, but in the end realized that it it couldn't be fully eliminated, and to minimize it further required re-writing many of the existing drivers, which would potentialy reduce performance and increase complexity with very little 'gain'. It works 98% of the time now, and to make it work 99% of the time required a lot of work for only 1% gain. That 1% of gain in 'stability' may cost 10-15% in terms of performance (requiring constant checks for the hardware being gone), which I deemed to be an acceptable cost/benefit. Now, you may consider it acceptable, and the costs may be better/worse than what I predicted, so feel free to hack away on the code and see what falls out. IMO the costs far outweigh the benefits... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910260356.VAA17204>