Date: Thu, 04 Jan 2001 20:09:39 -0700 From: Warner Losh <imp@bsdimp.com> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: arch@freebsd.org, current@freebsd.org Subject: Re: Cardbus woes Message-ID: <200101050309.f0539d149502@harmony.village.org> In-Reply-To: Your message of "Wed, 03 Jan 2001 21:29:52 MST." <200101040429.f044Tqs12960@aslan.scsiguy.com> References: <200101040429.f044Tqs12960@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[[ This is drifting over into -arch, so I'm ccing there and asking
people to redirect there. ]]
[[ The context is what to do about certain kinds of locking with
pccard code raising the bigger issue of what to do with interrupts
and sleepers in a hostile environemnt ]]
In message <200101040429.f044Tqs12960@aslan.scsiguy.com> "Justin T. Gibbs" writes:
: I take that back. In pccbb_detach, you need a mechanism to ensure
: that you are no-longer executing in your interrupt handler prior to
: destroying the softc.
There are two sitautions where you need to worry about things.
The first one is where your ISR is interrupted and the thing that
interrupts it wants to blow away the device. I think that the current
pccard (eg oldcard) code queues an soft interrupt to deal with this so
it can't interrupt things, but maybe I'm misremembering. Or maybe it
does it badly enough to cause problems (I know this is different than
the pccbb case, since that's newcard).
The second is where you have sleepers that need to "drain" before you
can delete the device.
The first one strikes me as a special case of the second one, but
maybe it needs to be handled specially.
At the BSDcon removable device meeting (which I missed because I found
out about it too late), the idea was that the detach routine would
sleep until all the sleepers had woken up and exited. Then the detach
routine would complete. It was suggested that some provision be made
for telling the device that this was a forced detach, but I don't
think that was nailed down. I think that having the detach routine
call the bridge and ask it if the hardware is still there would come
close to answering this question. When the hardware is gone, detach
cannot return EBUSY and have that be meaningful. The hardware is
gone. Who cares if it is busy, it has to cope with it being ripped
untimely from the driver's grasp. Gone is gone :-).
One way to deal with this would be to have all devices that sleep do a
ref/deref on the device around the sleep. There would be an implicit
ref/deref in the ISR too. However, that strikes me as unworkable.
There are a lot of drivers that do a lot of sleeping and when they
wake up. This would require a massive pass through the entire device
driver tree (well, at least for the ones that can be removed). I also
don't like the idea of doing boatloads of locking/unlocking code on
every single interrupt, but maybe that's unavoidable.
One way around the interrupt context problem is to ensure that devices
are never removed from an interrupt context. Or are at least never
detached from an interrupt context. However, I'm not sure the concept
of an interrupt context still has meaning in the new threads for ISR.
Can an interrupt thread block and allow other non-interrupt threads to
run?
Warner
P.S. Here's two interfaces that I'd like to add to the bus interface
file. They try to implement part of the removable feature. They are
based on my talking to phk after the arch meeting I missed. I don't
see any other way to ensure that interrupts will terminate.
#
# Ask the bridge if the device is still there. If the bus doesn't
# support removal, then it should always return true. If the bus
# does support removal, this method must return the real status of
# the child. Generally this is done by asking the bridge chip to
# see if card is present or not.
#
# Drivers may call this routine from an interrupt context. Drivers
# may assume this call is relatively inexpensive. Bridge drivers
# that implement this call should endeavor to make this inexpensive.
#
METHOD int child_present {
device_t dev;
device_t child;
} DEFAULT bus_generic_child_present;
#
# Ask the bridge if this instance of a device can be removed. Drivers
# may call this at any time. The bus code must guarantee that the
# value returned from this function is invariant on a per instance
# basis so drivers may cache the results.
#
# Drivers do not necessarily know that a bus supports device removal
# based on the attachment. PCI has both hot-plug and non-hot-plug
# variants, for example.
#
METHOD int is_removable {
device_t dev;
device_t child;
} DEFAULT bus_generic_is_removable;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101050309.f0539d149502>