netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: jamal <hadi@cyberus.ca>
Cc: Stefan Rompf <srompf@isg.de>,
	"David S. Miller" <davem@redhat.com>,
	netdev@oss.sgi.com
Subject: Re: Patch resubmission: RFC2863 operstatus for 2.5.50
Date: Mon, 9 Dec 2002 22:55:32 -0500	[thread overview]
Message-ID: <20021210035532.GA22559@gtf.org> (raw)
In-Reply-To: <Pine.GSO.4.30.0212090810520.19181-100000@shell.cyberus.ca>

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

  parent reply	other threads:[~2002-12-10  3:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-26  9:22 Patch resubmission: RFC2863 operstatus for 2.5.49 Stefan Rompf
2002-11-26 10:15 ` David S. Miller
2002-11-26 15:36   ` Stefan Rompf
2002-12-03 22:22   ` Patch resubmission: RFC2863 operstatus for 2.5.50 Stefan Rompf
2002-12-04  0:52     ` Jeff Garzik
2002-12-04  9:44       ` Stefan Rompf
2002-12-04 18:15         ` Jeff Garzik
2002-12-04 13:11       ` jamal
2002-12-04 17:42         ` Jeff Garzik
2002-12-09 13:27           ` jamal
2002-12-09 23:10             ` Stefan Rompf
2002-12-10  3:55             ` Jeff Garzik [this message]
2002-12-12 13:21               ` jamal
2002-12-04 19:39     ` David S. Miller
2002-11-29 12:56 ` Patch resubmission: RFC2863 operstatus for 2.5.49 jamal
2002-12-03 23:04   ` Stefan Rompf
2002-12-04 13:06     ` jamal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021210035532.GA22559@gtf.org \
    --to=jgarzik@pobox.com \
    --cc=davem@redhat.com \
    --cc=hadi@cyberus.ca \
    --cc=netdev@oss.sgi.com \
    --cc=srompf@isg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).