From owner-svn-src-head@FreeBSD.ORG Fri Mar 12 08:49:44 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 B4EE6106564A; Fri, 12 Mar 2010 08:49:44 +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 86E0C8FC1A; Fri, 12 Mar 2010 08:49:44 +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 0D1AD46B39; Fri, 12 Mar 2010 03:49:42 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: <4B99FF0A.5080504@elischer.org> Date: Fri, 12 Mar 2010 08:49:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <385F840D-4011-443C-8FC9-FAB9FDF211DF@freebsd.org> References: <201003111756.o2BHukJu042449@svn.freebsd.org> <9ace436c1003111530s3bd0de9cq451671909fb6aa64@mail.gmail.com> <5ADB6F0D-11F1-4F9F-87A0-64F57063981E@freebsd.org> <9ace436c1003112352l3b2505ceq63d9c78954520497@mail.gmail.com> <9ace436c1003120011v3c627aadka2e57615ae01fe6f@mail.gmail.com> <8726950E-5110-4FE1-90BB-B4205D637764@freebsd.org> <9ace436c1003120030m39f518basc77c7cff40299008@mail.gmail.com> <4B99FE46.6090001@elischer.org> <4B99FF0A.5080504@elischer.org> To: Julian Elischer X-Mailer: Apple Mail (2.1077) Cc: svn-src-head@freebsd.org, Qing Li , 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 08:49:44 -0000 On Mar 12, 2010, at 8:44 AM, Julian Elischer wrote: >>>>> I'm confused about Julian's proposal because it seems to me that = we already know when a driver hasn't set or is unable to determine the = link state: it will (should) be set to LINK_STATE_UNKNOWN by default. >=20 > the question is whether there is any other meaning for this state. > For example "I have not started up yet" Right now LINK_STATE_UNKNOWN conflates three different conditions: (1) I haven't and won't ever set the link state (2) I haven't yet, but may in the future set the link state (3) I wanted to check the link state, and the hardware is $*$**=A3*@@ so = I left or set this value instead My preferred solution is to advertise driver capabilities via the driver = capabilities flag, if_capabilities, and define a new flag = IFCAP_LINKSTATE (or something similar) that allows a driver to declare = that it is able to determine link state. If the flag is set, then = components like ECMP, but also dhclient, can reasonably expect that the = driver will do its best to provide link state information, addressing = the difference between (1) and (2) when a value of LINK_STATE_UNKNOWN is = found. If we are able to explicitly handle (3) in any of our drivers, then a = new link state definition should be defined, LINK_STATE_ERROR, which = should be set by the driver if it declared ICAP_LINKSTATE but was = unable, due to hardware failure, to check it. Robert=