cvs commit: src/sys/net if_tap.c

[Roman Kurakin]

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
>
>
>  
>