From owner-freebsd-arch Thu Jan 4 19: 9:49 2001 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 4 19:09:42 2001 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 552C337B400; Thu, 4 Jan 2001 19:09:41 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.1/8.11.0) with ESMTP id f0539dl09789; Thu, 4 Jan 2001 20:09:40 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.8.3) with ESMTP id f0539d149502; Thu, 4 Jan 2001 20:09:39 -0700 (MST) Message-Id: <200101050309.f0539d149502@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Cardbus woes Cc: arch@freebsd.org, current@freebsd.org Reply-To: arch@freebsd.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> Date: Thu, 04 Jan 2001 20:09:39 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ 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-arch" in the body of the message