From owner-freebsd-arch Tue Oct 26 11:30:41 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 9487F14C32 for ; Tue, 26 Oct 1999 11:30:38 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA23490 for ; Tue, 26 Oct 1999 20:30:27 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA22052 for freebsd-arch@freebsd.org; Tue, 26 Oct 1999 20:30:25 +0200 (MET DST) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 3214B14D58 for ; Tue, 26 Oct 1999 11:29:40 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (ind.alcatel.com 2.3 [OUT])) id LAA21253; Tue, 26 Oct 1999 11:27:55 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA10433; Tue, 26 Oct 1999 11:27:55 -0700 Received: from softweyr.com (dyn7.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA29107; Tue, 26 Oct 99 11:27:37 PDT Message-Id: <3815F2A0.FA3442F4@softweyr.com> Date: Tue, 26 Oct 1999 12:27:44 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Randell Jesup Cc: Nate Williams , Terry Lambert , imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Randell Jesup wrote: > > Nate Williams writes: > > >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. The PCMCIA spec had nothing to do with Microsoft, and wasn't designed for things like modems, network cards, and disk drives. In case you've forgotten, or never knew, it was a Personal Computer MEMORY CARD specification, and it was not expected that changes would be queued to the devices, but rather written directly. This is a HARDWARE spec, originally developed by Data I/O and later munged by a cast of thousands. It is arguable that any I/O performed to a PCMCIA device should be done entirely synchronously so that the operation can succeed or fail without the possibility of the card being removed AFTER the operation has been queued but before it completes. This would, of course, blow any chance of reasonable performance. > >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. That's a good answer. Let's get all of the hardware vendors to scrap what they've done and create a working ejectable card design that will cost several times as much. That's real likely to happen. This is one of those things where you pay your money and take your prize, even if it's not much of a prize at all. > >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. > > 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. We can't do that, because the hardware has no capability to lock the card into the machine. If you just tell everyone "don't pop your PCCards out or your system will crash" they'll just accuse you of being incompetent and move on to a system that does it correctly 95% or 98% of the time. > Of course, it depends on what > problem we're talking about here - if the consequence is much less > severe than crashing, then that's different, and minimizing the chance > of it may be reasonable. You're talking more about a tradeoff in boundary conditions. Would you rather have it do something nefarious during 1% of card ejections but otherwise work quite well, or have it never do anything stupid at all but deliver such abysmal performance it is unusable even for those who never eject cards while the system is running? > > 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... > > Perhaps you should fill us in on the costs and benefits, and > we may all come to agree with you once we know the issues. It doesn't > hurt to hash it out in public, which also (I assume) gets captured for > the record. Ah, discussing the issues involved is quite a reasonable thing to do. Assuming those who have gone before you are idiots who just don't under- stand how to code correctly is probably not. Perhaps you just didn't phrase your question well? I'm certainly willing to give you chapter and verse on what a poor idea the PCMCIA ejection notification is, and some of the other weaknesses in the spec, but having a copy of the spec or the "PCMCIA System Architecture" book (ISBN: 0201409917) handy will help. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message