From owner-freebsd-arch@FreeBSD.ORG Sat May 22 05:57:16 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 5F43F1065687 for ; Sat, 22 May 2010 05:57:16 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBEBE8FC0A for ; Sat, 22 May 2010 05:57:15 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 4so1805457fxm.13 for ; Fri, 21 May 2010 22:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=qePCSvWnytw7orcgQDyxcSRLpBFrtvZrxNLKH8HXwDw=; b=SLMhk8Fv9PjN7+WOPLyf19sO+GFR6Hn2x5YaVXEfAWfMMlRt2QoDl58GxauNPk71LY FTLARniF2cEhkhKAgEz+cJGFZoRGxcwodDhD3EcUcvww1skFOIV0+tBhku5+HnJg7Dsg le2DTSE+XJwuuRT99qcmG+WitAQ4IvZQkLsu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=R+HBezJTdDF4oZiSUlSUILcUjO7AQYxG4sUmID8Y98gn6vZWQvBAc1/zcbxaRevsIF 2mYICzAV0KEy0wWGMhhYSjnJ1vVrET4QN83j5ZR424+jswGrzUS3q81N8WytAVxpBR4Q voKJAqCZrF6SdJhhew2LQwCstwCNxue2P8JkY= Received: by 10.223.92.152 with SMTP id r24mr2287725fam.74.1274507835483; Fri, 21 May 2010 22:57:15 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id r12sm8018996fah.20.2010.05.21.22.57.14 (version=SSLv3 cipher=RC4-MD5); Fri, 21 May 2010 22:57:14 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BF77229.3050205@FreeBSD.org> Date: Sat, 22 May 2010 08:56:57 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.24 (X11/20100402) MIME-Version: 1.0 To: "M. Warner Losh" References: <4BF751DD.7020701@FreeBSD.org> <20100521.230703.1076064300569247858.imp@bsdimp.com> In-Reply-To: <20100521.230703.1076064300569247858.imp@bsdimp.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 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:57:16 -0000 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. > 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. > 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. > 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. -- Alexander Motin