Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Oct 1999 20:26:13 -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.10.9910242017170.89788-100000@beppo.feral.com>
In-Reply-To: <199910240608.AAA34462@harmony.village.org>

next in thread | previous in thread | raw e-mail | index | archive | help

> What I really want is a kernel signal mechanism which will start a
> rundown of the driver thread which is not allowed to touch hardware,
> but can only free resources used by the driver.  We have lots of tight
> loops in drivers in the kernel and it seems unwise to pessimize those
> so that this race can be dealt with...

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.

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.

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?

-matt






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?Pine.BSF.4.10.9910242017170.89788-100000>