From owner-freebsd-drivers@FreeBSD.ORG Sun Apr 8 03:14:43 2012 Return-Path: Delivered-To: drivers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AE18106564A; Sun, 8 Apr 2012 03:14:43 +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 EB7AD8FC08; Sun, 8 Apr 2012 03:14:42 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q383D76o076900 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 7 Apr 2012 21:13:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4F80579B.4040205@freebsd.org> Date: Sat, 7 Apr 2012 21:13:06 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120407125056.GS2358@deviant.kiev.zoral.com.ua> <4F80579B.4040205@freebsd.org> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 07 Apr 2012 21:13:07 -0600 (MDT) 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: Sun, 08 Apr 2012 03:14:43 -0000 On Apr 7, 2012, at 9:04 AM, 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. >>=20 >> 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. >>=20 >> 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. >>=20 >=20 > 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. Well, there's a problem here. You never know that you've attached = everything, so you could never really call it. Many busses enumerate = asynchronously, so it may be hard to get the semantics that you desire = unless the two devices you want to coordinate are in the static part of = the tree. Warner