From owner-freebsd-arch@FreeBSD.ORG Sat Sep 5 17:15: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 37574106566C; Sat, 5 Sep 2009 17:15: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 ED5028FC08; Sat, 5 Sep 2009 17:15:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n85HDPOc017548; Sat, 5 Sep 2009 11:13:25 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 05 Sep 2009 11:14:46 -0600 (MDT) Message-Id: <20090905.111446.500055027.imp@bsdimp.com> To: attilio@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> References: <3bbf2fe10909041546y2b5633e1ue063955568df1a06@mail.gmail.com> <20090904.172310.-1939841993.imp@bsdimp.com> <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@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 17:15:28 -0000 Attilio, [[ trimmed ]] Sounds like we're getting closer to closure... In message: <3bbf2fe10909050812l4340f679h6a4d7dae1daa3bf8@mail.gmail.com> Attilio Rao writes: : Bah, sorry, I kept reading it as DS_ rather than DIS_ . : Anyways, what do you think about, for 9.0, just having one interface : and remove the DIS_* bloat? [ disconnect between libdevinfo and kernel types ] I think we should have both for either 8.x or 9.x (depending on what the RE@ will permit), and then drop the DIS_ the next release after that. : Ok, if you are strongly against it, we can remove them, I just think : they will be harmless and a good reminder. [ Have the code there to document/enforce protocol wrt state ] I think I'd prefer not to have it, but could easily allow it if we know that it causes no harm and can be reasonably sure that it is close to what the final protocol will be. Warner