From owner-svn-src-head@FreeBSD.ORG Fri Mar 12 07:47:59 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92890106566B; Fri, 12 Mar 2010 07:47:59 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 67D038FC17; Fri, 12 Mar 2010 07:47:59 +0000 (UTC) Received: from [192.168.2.102] (host86-180-59-125.range86-180.btcentralplus.com [86.180.59.125]) by cyrus.watson.org (Postfix) with ESMTPSA id 5734C46B06; Fri, 12 Mar 2010 02:47:58 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <9ace436c1003111618t28dba8d8x19aeff2acff0c489@mail.gmail.com> Date: Fri, 12 Mar 2010 07:47:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201003111756.o2BHukJu042449@svn.freebsd.org> <9ace436c1003111530s3bd0de9cq451671909fb6aa64@mail.gmail.com> <9ace436c1003111539t2af8439cn315c695d4b90e28d@mail.gmail.com> <9ace436c1003111618t28dba8d8x19aeff2acff0c489@mail.gmail.com> To: Qing Li X-Mailer: Apple Mail (2.1077) Cc: Juli Mallett , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r205024 - head/sys/net X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 07:47:59 -0000 On Mar 12, 2010, at 12:18 AM, Qing Li wrote: > You definitely have a very good point here. I was a bit surprised > during debugging that the link state is not consistently initialized > and by far not enforced across all of the drivers. Admittedly I = checked > the most commonly deployed devices and they are in good state. >=20 > I certainly appreciate your patience on this one and will try to get > it resolved quickly. One of the reasons drivers don't do this consistently his that = historically, hardware has not consistently supported link state = detection. This now does seem to be a standard feature, but I think it = would be useful to continue to support some notion of a driver not = supporting it, hence my thoughts on a link state capability: only test = link state if the driver can implement it. Otherwise, you end up with a = link state undefined state, which likely comes to much the same thing, = and is presumably what in practice you get today on drivers that don't = set it. Robert=