From owner-freebsd-drivers@FreeBSD.ORG Sat Apr 7 15:48:36 2012 Return-Path: Delivered-To: drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEF0A1065676; Sat, 7 Apr 2012 15:48:36 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from argol.doit.wisc.edu (argol.doit.wisc.edu [144.92.197.212]) by mx1.freebsd.org (Postfix) with ESMTP id 8F2A28FC0A; Sat, 7 Apr 2012 15:48:36 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0M24004009908500@smtpauth3.wiscmail.wisc.edu>; Sat, 07 Apr 2012 10:48:36 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.67.9]) by smtpauth3.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0M24000DK98YBK10@smtpauth3.wiscmail.wisc.edu>; Sat, 07 Apr 2012 10:48:35 -0500 (CDT) Date: Sat, 07 Apr 2012 10:48:34 -0500 From: Nathan Whitehorn In-reply-to: <20120407151514.GW2358@deviant.kiev.zoral.com.ua> To: Konstantin Belousov Message-id: <4F8061D2.4030507@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.67.9 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.7.153916, SenderIP=76.210.67.9 References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <4F80579B.4040205@freebsd.org> <20120407151514.GW2358@deviant.kiev.zoral.com.ua> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.2) Gecko/20120311 Thunderbird/10.0.2 Cc: current@freebsd.org, drivers@freebsd.org Subject: Re: device_attach(9) and driver initialization X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 15:48:37 -0000 On 04/07/12 10:15, Konstantin Belousov wrote: > On Sat, Apr 07, 2012 at 10:04:59AM -0500, Nathan Whitehorn wrote: >> On 04/07/12 07:50, Konstantin Belousov wrote: >>> Hello, >>> there seems to be a problem with device attach sequence offered by newbus. >>> Basically, when device attach method is executing, device is not fully >>> initialized yet. Also the device state in the newbus part of the world >>> is DS_ALIVE. There is definitely no shattering news in the statements, >>> but drivers that e.g. create devfs node to communicate with consumers >>> are prone to a race. >>> >>> If /dev node is created inside device attach method, then usermode >>> can start calling cdevsw methods before device fully initialized itself. >>> Even more, if device tries to use newbus helpers in cdevsw methods, >>> like device_busy(9), then panic occurs "called for unatteched device". >>> I get reports from users about this issues, to it is not something >>> that only could happen. >>> >>> I propose to add DEVICE_AFTER_ATTACH() driver method, to be called >> >from newbus right after device attach finished and newbus considers >>> the device fully initialized. Driver then could create devfs node >>> in the after_attach method instead of attach. Please see the patch below. >>> >> Something like this would also be very useful for drivers that need to >> interact across the device tree, if newbus called it only after all >> drivers have been attached. Drivers that need to see other potentially >> attached drivers now need to do some hacks with SYSINIT. Would it be >> possible to do this? I don't think it changes the functionality you need. > I am definitely fine with postponing a call further, but I am not sure > how to define that point and how to implement your proposal. I am mostly > thinking of the case of kld being loaded, since for compiled-in drivers, > there is simply no usermode to make the havoc during attach. > > For the boot time attachments, I am not sure when to declare the end. > E.g. USB does asynchronous device discovery. > > Could you prototype a change that would do what you propose ? The idea would be to have something that walks the tree and calls it from root_bus_configure(), and otherwise does what your patch does. But it is hard to have it work right for modules, and maybe is too invasive anyway. I'll think about it some more and try to mock something up if it doesn't turn out to be unworkable. -Nathan