cvs commit: src/sys/net if_tap.c

Sam Leffler sam at errno.com
Fri Aug 13 11:56:51 PDT 2004


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


More information about the cvs-src mailing list