Date: Tue, 26 Oct 1999 12:27:44 -0600 From: Wes Peters <wes@softweyr.com> To: Randell Jesup <rjesup@wgate.com> Cc: Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <3815F2A0.FA3442F4@softweyr.com> 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
Randell Jesup wrote:
>
> Nate Williams <nate@mt.sri.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3815F2A0.FA3442F4>