From owner-cvs-src@FreeBSD.ORG Fri Aug 13 18:56:51 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 8857216A4CE; Fri, 13 Aug 2004 18:56:51 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40F4B43D53; Fri, 13 Aug 2004 18:56:51 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id i7DIukWi049177 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 13 Aug 2004 11:56:46 -0700 (PDT) (envelope-from sam@errno.com) From: Sam Leffler Organization: Errno Consulting To: Roman Kurakin Date: Fri, 13 Aug 2004 11:59:30 -0700 User-Agent: KMail/1.6.1 References: <200408131114.46274.sam@errno.com> <411D0795.6010406@cronyx.ru> In-Reply-To: <411D0795.6010406@cronyx.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408131159.30682.sam@errno.com> 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:56:51 -0000 On Friday 13 August 2004 11:25 am, Roman Kurakin wrote: > 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. The instances that I am aware of are misdesigns that need correcting. Folks that query IFF_UP to mean something it is not may need an alternative state bit but overloading IFF_UP to mean something it does not is wrong. FWIW netbsd does this correctly. I can't comment on PPP as I haven't looked at the code. Sam