Date: 26 Oct 1999 11:14:19 +0000 From: Randell Jesup <rjesup@wgate.com> To: nate@mt.sri.com (Nate Williams) Cc: Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <ybuln8ql6gk.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Nate Williams's message of "Mon, 25 Oct 1999 21:56:05 -0600" References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams <nate@mt.sri.com> writes:
>> 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.
>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.
>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?
>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. 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.
>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.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
CDA II has been passed and signed, sigh. The lawsuit has been filed. Please
support the organizations fighting it - ACLU, EFF, CDT, etc.
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?ybuln8ql6gk.fsf>