Date: Fri, 13 Aug 2004 11:14:46 -0700 From: Sam Leffler <sam@errno.com> To: John Polstra <jdp@polstra.com> Cc: Roman Kurakin <rik@cronyx.ru> Subject: Re: cvs commit: src/sys/net if_tap.c Message-ID: <200408131114.46274.sam@errno.com> In-Reply-To: <XFMail.20040813103440.jdp@polstra.com> References: <XFMail.20040813103440.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408131114.46274.sam>