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
next prev 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).