Date: Mon, 25 Oct 1999 11:53:21 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Warner Losh <imp@village.org> Cc: arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <Pine.BSF.4.05.9910251146580.27785-100000@semuta.feral.com> In-Reply-To: <199910251841.MAA42028@harmony.village.org>
index | next in thread | previous in thread | raw e-mail
On Mon, 25 Oct 1999, Warner Losh wrote: > In message <Pine.BSF.4.10.9910242017170.89788-100000@beppo.feral.com> Matthew Jacob writes: > : Presumably the interrupt that notifies one that a card has been pulled is > : actually then managed by the bus device driver for that bus. This should > : ensure that the the bus nexus controlller is notified that the state of > : the hardware is changed. > > Yes. That is correct. > > : 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. 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. > become active. At least that's what it appears to be in the few I've > seen. Most of the problems would be solved if I could detach the > device before unmapping the interrupts, which is the part I needed to > think about... Or rather look hard at the code to see why it is doing > what it is doing and fix it... > > : For systems I'm more familiar with, explicit obligate parent-child > : relationships have these specific notification mechanisms specified on a > : per parent-child type basis. It's hard to generalize such mechanisms into > : a usable general event notification mechanism because each bus has > : different possible async events. A PC cardbus has removal/insertion, a > : fibre channel arbitrated loop has LIP and then (re)arbitration for > : AL_PAs- who knows what Compact PCI provides? > : > : What does newbus provide for this? > > newbus provides methods, but that is about it.. However, methods are > easily ignored/defaulted so one can send arbitrary method call message > to a tree or subtree and have sane things happen. > Well, it sounds like you can do what you want then! :-) Except you seem to want a more general event mechanism so that drivers can know that their resources may have changed? Now that I think about it, this could possibly be a useful extension but would require a callback entry- and callback entries are bad for loadable drivers. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910251146580.27785-100000>