From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 7 12:25:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D43106566C; Sat, 7 Jul 2012 12:25:39 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 3E8308FC1B; Sat, 7 Jul 2012 12:25:39 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 13A0911D96F; Sat, 7 Jul 2012 12:25:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: Date: Sat, 7 Jul 2012 14:25:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Arnaud Lacombe X-Mailer: Apple Mail (2.1278) Cc: FreeBSD Hackers , FreeBSD Current Subject: Re: Interfacing devices with multiple parents within newbus X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jul 2012 12:25:39 -0000 Am 06.07.2012 um 17:33 schrieb Arnaud Lacombe: > I assume you are talking about = devclass_get_device()/device_find_child(). >=20 > That's neither correct nor robust in a couple of way: > 1) you have no guarantee a device unit will always give you the same = resource. > 2) there is no reference counting on the returned device. > 3) there is no track record of the reference being given. >=20 > About (1), lower unit devices can fails to attach[0], thus newly > attached bus will now have a negative offset. >=20 > About (2) and (3), referenced device (think KLD) might go away and the > child will not be told. In this situation, I want the child to be > detached prior to its parent. >=20 > As such, looking up other node by name would fit in what I call > "bypassing newbus purpose". I might just as well export a damn > function pointer and make my life easier. I believe there is one more thing that needs to be addressed, which I = ran into while trying to do the arge/mdio attachment: 4) the device attach method may require access to the other device to = complete the attachment, but that other might not be attached yet. Circular dependencies nonwithstanding, it would be highly desirable for = a device driver developer to be able to simply declare all prerequisites = for attachment, and have newbus call attach only after everything is = there. Right now, the drivers attach method is called by the parent bus = as soon as enumeration is completed. A notification mechanism (similar to the devfs notification but with an = exposed KPI) might be an alternative, as mentioned in this thread. Stefan --=20 Stefan Bethke Fon +49 151 14070811