From owner-freebsd-arch@FreeBSD.ORG Sat Sep 5 15:30:28 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F7B1065676; Sat, 5 Sep 2009 15:30:28 +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 052278FC22; Sat, 5 Sep 2009 15:30:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n85FTGAR016489; Sat, 5 Sep 2009 09:29:16 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 05 Sep 2009 09:30:37 -0600 (MDT) Message-Id: <20090905.093037.1927920092.imp@bsdimp.com> To: attilio@freebsd.org From: "M. Warner Losh" In-Reply-To: <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> References: <20090904.172310.-1939841993.imp@bsdimp.com> <20090905.023634.831786645.imp@bsdimp.com> <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: NEWBUS states 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, 05 Sep 2009 15:30:28 -0000 In message: <3bbf2fe10909050817w4e8da3adxd8e431749b432070@mail.gmail.com> Attilio Rao writes: : 2009/9/5 M. Warner Losh : : > In message: <20090904.172310.-1939841993.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : OK. Let me ponder based on that... It might be better for this round : > : of changes to leverage off the device 'flags' field to indicate that : > : we're attaching/detaching. This would not break the : > : device_is_attached() usage, and would solve the interlock problem : > : nicely. While it isn't as aesthetically pleasing as the new states, : > : it would allow us to easily MFC it without API/ABI breakage. This : > : field surely would be covered by the same set of locks as the state : > : field. : > : : > : I know that there's a good aesthetic argument to be made against this, : > : but on the other hand 'compatibility' hacks can violate one's : > : aesthetics. We can migrate to a more pleasing state-based model in 9 : > : and reduce the risk to other code from changing its semantics at this : > : late date. : > : > For a version of this hack, see : > http://people.freebsd.org/~imp/newbus-flags.diff : : So you propose to offer the transition on the device flags instead : than the device states? : That is an interesting approach mostly because it won't require an ABI : breakage, but let me think about locking implications with it as I : want to review some code and came up with a patch/thoughts in some : hours. Please do. I wanted this to provoke thought and experimentation. While not the most beautiful approach, it is one that we can use to get around the API/ABI issues. Please let me know how it works out... The assumption in the patch is that locking requirements for state and flags are identical... Warner