From owner-cvs-src@FreeBSD.ORG Fri Aug 13 18:29:06 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8BC816A4CE for ; Fri, 13 Aug 2004 18:29:06 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2870443D48 for ; Fri, 13 Aug 2004 18:29:06 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7DIQ1ps051021 for cvs-src@FreeBSD.org.checked; (8.12.8/vak/2.1) Fri, 13 Aug 2004 22:26:01 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i7DIOMmE050950; (8.12.8/vak/2.1) Fri, 13 Aug 2004 22:24:22 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <411D0795.6010406@cronyx.ru> Date: Fri, 13 Aug 2004 22:25:25 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <200408131114.46274.sam@errno.com> In-Reply-To: <200408131114.46274.sam@errno.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org cc: John Polstra Subject: Re: cvs commit: src/sys/net if_tap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2004 18:29:07 -0000 Sam Leffler wrote: >On Friday 13 August 2004 10:34 am, John Polstra wrote: > > >>On 13-Aug-2004 Roman Kurakin wrote: >> >> >>>John Polstra wrote: >>> >>> >>>>On 13-Aug-2004 Roman Kurakin wrote: >>>> >>>> >>>>>John Polstra wrote: >>>>> >>>>> >>>>>>That's pretty much correct. IFF_UP is an administrative control >>>>>>that expresses the desired state of the interface. The driver never >>>>>>changes IFF_UP. IFF_RUNNING is the driver's idea of the _actual_ >>>>>> >>>>>> >>>>>PPP state machine can remove IFF_UP. For example if connection is not >>>>>persistent and link >>>>>was broken for any reason. >>>>> >>>>> >>>>I call that a bug. >>>> >>>> >>>This is not a bug, this is feature of protocol. Some times link should >>>go down (or other >>>state from which it could go up only by administrator (or program) >>>intervention). >>> >>> >>Sorry, but I disagree. PPP should clear IFF_RUNNING in that case, >>but should leave IFF_UP untouched. >> >> > >IFF_RUNNING was intended to mark a device "ready for use" and should be >managed by the driver. IFF_UP was to be administratively controlled and any >automated change is contrary to the original intent/design. The only case >that I'm aware of where IFF_UP is touched as a side-effect of another >operation is when setting an interface's address and I consider that a bug. >Unfortunately fixing it has widespread consequences and each time I've tried >I've given up in disgust. > > Ok. Since IFF_UP is used this way by many implementations we have to agree that this is normal behavior that was introduced by evolution and practice like word spelling could be changed from its origin. rik > Sam > > > >