Date: Mon, 25 Oct 1999 13:02:30 -0600 From: Nate Williams <nate@mt.sri.com> To: mjacob@feral.com Cc: Warner Losh <imp@village.org>, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <199910251902.NAA14532@mt.sri.com> In-Reply-To: <Pine.BSF.4.05.9910251146580.27785-100000@semuta.feral.com> References: <199910251841.MAA42028@harmony.village.org> <Pine.BSF.4.05.9910251146580.27785-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > : This does nothing for threads that were active at the time of the > > : interrupt. In this case, either the hardware is sane enough to continue to > > : provide some rational non-faulting access (in the case of memory mapping), > > : or you have to design a framework such that when the interrupt occurs, and > > : the nexus driver now knows how to remap any memory mappings so that a safe > > : non-faulting (if nonsensical) access can occur. Then some additional > > : mechanism which notifies the actual node driver that things have changed > > : will be invoked. > > > > Hmmm. I could do this, but do not know of any way of mapping I/O > > ports sanely. The problem appears to be driver busy waits for bits to > > I/O instructions don't cause faults if the port doesn't exist, right? They > just are /dev/null for writes and return nonsense for reads. How do you differentiate between 'good' reads and 'nonsensical' reads? > I suppose that if a driver is polling an I/O port, and it knows it's on a > bus where this I/O port can go away, it should check for other status, no? > Heck, you shouldn't have drivers poll forever anyway. Agreed, but these sort of assumptions exist today, and re-writing the driver is non-trivial, and adds additional complexity, especially since FreeBSD doesn't have the infrastructure to deal with these kinds of changes (yet). 1) How do you recognize 'garbage'? 2) What do you do when you determine a piece of hardware is gone/bad? 3) What about dependencies? (If the disk is bad, do you unmount the FS, flush the buffers, etc...?) Error handling is *HARD WORK*, and it's difficult to make a generic infrastructure to deal with all of the different kinds of errors that may occur. It's alot easier to use the standard FreeBSD approach to the problem. "You've got broken hardware, fix it and FreeBSD will work better." :( 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?199910251902.NAA14532>