| To: | hadi@xxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH] (3/4) bridge linkstate handling |
| From: | Stephen Hemminger <shemminger@xxxxxxxx> |
| Date: | Thu, 29 Jul 2004 09:31:20 -0700 |
| Cc: | "David S. Miller" <davem@xxxxxxxxxx>, bridge@xxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <1091103164.1046.591.camel@xxxxxxxxxxxxxxxx> |
| Organization: | Open Source Development Lab |
| References: | <20040728162413.0de73ea3@xxxxxxxxxxxxxxxxxxxxx> <1091103164.1046.591.camel@xxxxxxxxxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On 29 Jul 2004 08:12:44 -0400 jamal <hadi@xxxxxxxxxx> wrote: > On Wed, 2004-07-28 at 19:24, Stephen Hemminger wrote: > > This makes bridge port status reflect both the state of the interface > > from software (up/down) and the carrier. It makes STP handle link failure > > (cable breakage, etc). The original concept comes from a > > Mark Ruijter <bridge@xxxxxxxxxxx> who implemented it differently. > > My way is simpler and requires no polling. > > > > Obviously, this link state detection will only work if the network card > > handles the events properly. > > > > nice. Does this entrench STP further in the kernel? > Still planning to move it out to user space? The same logic would apply in user space, it would just use the netlink events that come from netlink messages (RTM_NEWLINK) rather than notifier chain (NETDEV_CHANGE). |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 1/6 2.5] e100 - restore speed/duplex/autoneg settings after diagnostic test, Jeff Garzik |
|---|---|
| Next by Date: | RE: [PATCH] (3/4) bridge linkstate handling, Eble, Dan |
| Previous by Thread: | Re: [PATCH] (3/4) bridge linkstate handling, jamal |
| Next by Thread: | RE: [PATCH] (3/4) bridge linkstate handling, Eble, Dan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |