Date: Fri, 13 Aug 2004 12:25:35 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Roman Kurakin <rik@cronyx.ru> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/net if_tap.c Message-ID: <XFMail.20040813122535.jdp@polstra.com> In-Reply-To: <411D04FE.70304@cronyx.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13-Aug-2004 Roman Kurakin wrote: > 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. >> > But in that case we need some other way to bring line up again, since we > unable just > to ifconfig XXX up. This is possible to implement but very inconvenient. Actually (having thought about it some more), PPP probably shouldn't even clear IFF_RUNNING in that case. IFF_RUNNING is not supposed to reflect whether the link is active or not. It just reflects whether the driver software is capable of functioning. For example, Ethernet drivers don't change IFF_RUNNING if the link goes away. I don't know for sure how PPP ought to handle the case you're describing. It should mark the link as down (not active) but leave IFF_RUNNING set. Then it should either retry periodically to establish an active link; or it should let the user do that manually via "ifconfig ppp0 down; ifconfig ppp0 up". > Could you describe why is so bad that some administrative action > could be canceled due to protection or some other reasons by device > state machine? Especially if users have a choice to allow this > action or not. If users have a choice this action could be treated > on behalf of administrator and thus like administrative action. Well, it is standard practice to separate administrative controls from driver status bits. That's how all the relevant IEEE standards describe things, for instance. The standards define separate variables, for example "adminEnable" and "operEnable" to reflect the administratively requested state and the actual state, respectively. The first is changed only by management actions, and the second is changed only by the software/hardware/whatever. John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20040813122535.jdp>