From owner-freebsd-arch@FreeBSD.ORG Sat May 22 06:19:53 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B7E1065794; Sat, 22 May 2010 06:19:53 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8720A8FC19; Sat, 22 May 2010 06:19:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o4M6FGZI077019; Sat, 22 May 2010 00:15:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 22 May 2010 00:15:44 -0600 (MDT) Message-Id: <20100522.001544.725436840180021448.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4BF77229.3050205@FreeBSD.org> References: <4BF751DD.7020701@FreeBSD.org> <20100521.230703.1076064300569247858.imp@bsdimp.com> <4BF77229.3050205@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: Device driver unload X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2010 06:19:54 -0000 In message: <4BF77229.3050205@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <4BF751DD.7020701@FreeBSD.org> : > Alexander Motin writes: : > : I think we have some inconsistency around device driver unloading. When : > : devices gets no driver during boot, bus driver receives : > : BUS_PROBE_NOMATCH() call, allowing to power-down the device. But if : > : device looses driver after module unload - nothing happens. : > : > Correct. : > : > : So my question is: shouldn't we call either device_probe_and_attach() or : > : BUS_PROBE_NOMATCH() for devices detached due to driver unload? : > : > I don't think so. We're not really setup to do that. If we were to : > do that, then reloading the old driver would break since the new, : > alternative driver wouldn't detach when we kldload the new one. This : : Yes, I consider this. It is indeed a problem, but it is not new, it is : already exist. Now I can't load ahci(4) driver in runtime after ata(4) : grabbed devices on boot. That's the opposite problem... : > is an important case to keep working, even if there might be some : > slight benefit to your proposed change. There's some infrastructure : > to do this already, in the DF_REBID stuff I did a while ago. : : Yes, I've seen it, but I can hardly see how can it be really used, while : calling probe require device to be detached first. It will not be nice : to loose root file system on loading sound driver. DF_REBID wouldn't change that at all. You don't detach unless there's a newer, better driver. And you don't detach if the driver is currently still in use. The biggest reason I've not enabled it is that I've not audited the tree to know if other driver's probe routines are safe to call while the driver is attached... : > Alternatively, we'll need to fix the so-called '/dev/foot' patches to : > give direct control. : : What is this? Is it something to control attach/detach from user-level? : I would really like to see such mechanisms, but I have no good idea how : to reliably identify device when it's name changes with driver change. : It would be nice to be able to address device via attachment point, but : it seems too bus-specific now. There's already a bus-supplied location string... That could be used to make it work... : > BUS_PROBE_NOMATCH likely isn't a bad choice to call on detach, : > however. Oh, and we'll need to unset DF_NOMATCH on attach. At least : > I think that's the right place... : : Sure. Warner