All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Pantelis Koukousoulas <pktoss@gmail.com>, netdev@vger.kernel.org
Subject: Re: [PATCH] Make virtio_net support carrier detection
Date: Thu, 12 Mar 2009 07:43:39 -0400	[thread overview]
Message-ID: <1236858219.14863.18.camel@localhost.localdomain> (raw)
In-Reply-To: <200903121946.24847.rusty@rustcorp.com.au>

On Thu, 2009-03-12 at 19:46 +1030, Rusty Russell wrote:
> On Thursday 12 March 2009 18:14:44 Pantelis Koukousoulas wrote:
> > On Thu, Mar 12, 2009 at 9:29 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > > On Wednesday 11 March 2009 22:27:22 Pantelis Koukousoulas wrote:
> > >> For now the semantics are simple: There is always carrier.
> > >>
> > >> This allows a seamless experience with e.g., qemu/kvm
> > >> where NetworkManager just configures and sets up
> > >> everything automagically.
> > >
> > > So, NetworkManager ignores the device because it doesn't support
> > > carrier detection?
> > 
> > It doesn't ignore it, it just doesn't enable it by default, like it does for
> > those that do report carrier.
> > 
> > But the user experience is that on real hardware you just boot a livecd
> > and see your network "just working" (and the familiar icon with the 2
> > computers indicating that), while under e.g., KVM/virtio you get
> > non-working network / an icon with a red X and you have to
> > figure out to left click on it and select eth0 to get things to work.
> > 
> > Some newer versions of NetworkManager seem to assume that
> > if no carrier detection is supported then carrier is on by default
> > so it should work for those, but that assumption seems like
> > a worse hack than this patch :)
> 
> No, that's absolutely sane behavior, the previous was buggy.  If a network
> doesn't support carrier, you shouldn't look for it.
> 
> Since they've fixed this in Network Manager, I'm not tempted to lie about it
> in the driver (though the distributions might choose to).

The problem is that there's no "my carrier detection is accurate" flag
for drivers.  Drivers that don't support carrier detection (say, my
Belkin PCMCIA NE2k card) always report "carrier on", but of course don't
support carrier detection.  So when NetworkManager looks at the device
and sees "hey, there's a carrier!" it will activate it, because a
carrier means the cable is plugged in or the PHY *thinks* a cable is
plugged in.

So NetworkManager checks whether the device supports ethtool get_link or
MII register carrier status in lieu of a general kernel driver flag for
"I support carrier detection".

Carrier is not on/off, it needs to be tristate, like on/off/unknown.  If
it was unknown, NM could make an intelligent decision about this without
resorting to ethtool/MII checks.  But we don't have that.

Dan



  parent reply	other threads:[~2009-03-12 11:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1236772642-12705-1-git-send-email-pktoss@gmail.com>
2009-03-12  7:29 ` [PATCH] Make virtio_net support carrier detection Rusty Russell
2009-03-12  7:44   ` Pantelis Koukousoulas
2009-03-12  9:16     ` Rusty Russell
2009-03-12 10:23       ` Pantelis Koukousoulas
2009-03-12 11:05         ` Pantelis Koukousoulas
2009-03-12 11:43       ` Dan Williams [this message]
2009-03-12 12:47         ` Pantelis Koukousoulas
2009-03-12 12:52           ` David Miller
2009-03-12 12:58             ` Pantelis Koukousoulas
2009-03-12 13:03               ` David Miller
2009-03-12 13:10                 ` Pantelis Koukousoulas
2009-03-12 13:41             ` Dan Williams
2009-03-12 13:55               ` Dan Williams
2009-03-12 21:39             ` Rusty Russell
2009-03-12 23:47               ` Rusty Russell
2009-03-12 23:55                 ` Stephen Hemminger
2009-03-13  5:04                 ` Pantelis Koukousoulas
2009-03-13 19:01                 ` David Miller
2009-03-14  0:19                   ` Rusty Russell
2009-03-14 10:40                     ` Pantelis Koukousoulas
2009-03-14 11:33                       ` Pantelis Koukousoulas
2009-03-15 22:39                       ` Rusty Russell
2009-03-16  2:05                         ` Pantelis Koukousoulas
2009-03-16  2:58                     ` David Miller
2009-03-16  3:13                       ` Rusty Russell
2009-03-16  3:15                         ` David Miller
2009-03-14  0:23 Rusty Russell
2009-03-19  1:40 ` David Miller

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=1236858219.14863.18.camel@localhost.localdomain \
    --to=dcbw@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pktoss@gmail.com \
    --cc=rusty@rustcorp.com.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.