cvs commit: src/sys/net if_tap.c

[Sam Leffler]

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