From owner-freebsd-arch@FreeBSD.ORG Sat May 22 05:10:04 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 312F1106566C; Sat, 22 May 2010 05:10:04 +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 E81488FC0A; Sat, 22 May 2010 05:10:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o4M56ZuT076419; Fri, 21 May 2010 23:06:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 21 May 2010 23:07:03 -0600 (MDT) Message-Id: <20100521.230703.1076064300569247858.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4BF751DD.7020701@FreeBSD.org> References: <4BF751DD.7020701@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 05:10:04 -0000 In message: <4BF751DD.7020701@FreeBSD.org> Alexander Motin writes: : Hi. : : 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 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. Alternatively, we'll need to fix the so-called '/dev/foot' patches to give direct control. 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... : If there : is no alternative driver - device_probe_and_attach() also result in : BUS_PROBE_NOMATCH() call. Sounds good in theory. However, there's problems with this. We'll need to make a list of devices that are detached, and then call device_probe_and_attach() after we've completely unwound the module unload. There may be other issues here as well. I've not thought through the consequences of doing this with multiple module unloads. So, in short, we could do something like this, but we must do it very carefully. There's a lot of interrelated junk here, and I don't want to break useful cases that work today... Warner