netdev
[Top] [All Lists]

Re: Patch resubmission: RFC2863 operstatus for 2.5.50

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: Patch resubmission: RFC2863 operstatus for 2.5.50
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Mon, 9 Dec 2002 22:55:32 -0500
Cc: Stefan Rompf <srompf@xxxxxx>, "David S. Miller" <davem@xxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <Pine.GSO.4.30.0212090810520.19181-100000@xxxxxxxxxxxxxxxx>
References: <3DEE3E6E.30407@xxxxxxxxx> <Pine.GSO.4.30.0212090810520.19181-100000@xxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Mon, Dec 09, 2002 at 08:27:39AM -0500, jamal wrote:
> On Wed, 4 Dec 2002, Jeff Garzik wrote:
> > For ifAdminStatus, you have "up", "down", and "testing" states.  Since
> > we have no concept of a testing state, if we eliminate that we have "up"
> > and "down", two states we can obviously handle.
> >
> > For ifOperStatus, we have "up", "down" and "testing", which are
> > applicable (or not) to Linux as with ifAdminStatus.  Further we have
> > states "dormant", "unknown", "notPresent", "lowerLayerDown".  I'll
> > discuss each of these in detail.
> >
> > "dormant" - not used in Stefan's patch, which I agree with.
> > "unknown" - only used in Stefan's patch before interface is first up'd,
> > which is IMO inaccurate.  Accurate use of "up" and "down", to me,
> > implies -no- use of "unknown" state.  Because as soon as we are
> > initialized, all ethernet details are known, thus "down" is more
> > applicable.  The Linux net stack's atomicity is such that leaking an
> > "unknown" state would be a bug, too.
> > "notPresent" - analagous to Linux's netif_device_xxx, and Stefan's patch
> > acknowledges this.  However, the use of netif_device_xxx in drivers is
> > really only used when the hardware is suspended.  If hardware goes away,
> > the interface goes away too, almost immediately.
> > "lowerLayerDown" - not used in Stefan's patch, which I agree with.
> >
> > So, Stefan's 2nd patch really only adds "unknown" and "notPresent"
> > states to current behavior -- and the applicability of those states to
> > Linux is IMO questionable.
> >
> 
> If all he is adding are some enumerated types, theres no harm. I cant
> remember the details of the discussions - but we had long winding
> discussions on the different states.

I would summarize his patch as adding variable to represent literally
ifOperStatus, along with a lock and apparatus to set this variable.

The value may be deduced, without having to literally track it.


> Note you need both admin and operational status and physically thet may
> mean different things (think PPP and ethernet for example). You also need
> to properly reflect the status for all sorts of netdevices. As long as
> those requirements are met, then all is good. The RFC is not the final
> word but it draws from experiences people had for years doing this kind
> of stuff - so it is a good idea to draw from their experiences (but ok to
> ignore it if it sounds unrealistic).

I think we do agree on interpretation as you describe it here.
And the linkwatch patch is now in Linux 2.5.51.  I just think the
further patch to "track literally" ifOperStatus is not needed.  However,
that is presented as an opinion and RFC, not a statement of fact :)

        Jeff




<Prev in Thread] Current Thread [Next in Thread>