Date: Tue, 26 Oct 1999 09:25:03 -0600 From: Nate Williams <nate@mt.sri.com> To: Randell Jesup <rjesup@wgate.com> Cc: nate@mt.sri.com (Nate Williams), Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910261525.JAA18872@mt.sri.com> In-Reply-To: <ybuln8ql6gk.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <ybuln8ql6gk.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net>
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. > > Such as? Of course, just because the MS spec says you should be > able to pop out the hardware at any time doesn't mean you can't make > software that says "you MUST shut down the driver before removing the card > or you may lose all your work", but the problem with that is that it breaks > the user's expectations, especially if all the other vendors handle it. > Not to mention that it's a bad idea from a CHI standpoint. You're missing the point. What happens if I'm in the middle of a ISR when the device is popped out? How do I recognize that it's gone, when I'm expecting the hardware to respond to some request I've sent it? What happens when I'm reading a piece of memory that no longer exists? > >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. > > Then change the design. I can't. I don't control the hardware such that the software can be informed that the device is being removed *before* the hardware is removed. > >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'. > > Why can't it be fully eliminated? See above, plus previous emails sent on the topic. If that isn't enough, go read the specification and go think about the problem a little bit. And if this sounds harsh, it's not meant to, but trying to explain why it's a problem requires a little bit of experience trying to fix the problem plus some out of the box thinking about the problem. [ And yes, I've thought about the problem, plus I've coded up the existing suspend/resume code in FreeBSD to minimize the race, but I've not eliminated it since I believe it can't be eliminated completely. ] > When I pop a card out, it should _never_ crash. If there's no > way to avoid the chance of a crash (even 1%), you should not support > popping of (active) cards out at all. That's my point. You can claim to not support it (like Win98 does), but it doesn't stop people from doing it. If they do it it'll crash, so who looks bad, the OS or the person? 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?199910261525.JAA18872>