Message-ID: <alpine.LFD.2.21.1808040646290.25800@localhost.localdomain>
Date:   Sat, 4 Aug 2018 07:06:58 -0400 (EDT)
From:   "Robert P. J. Day" <rpjday@...shcourse.ca>
To:     Linux kernel ntedev mailing list <netdev@...r.kernel.org>
Subject: consequences of setting net_device_ops ndo_change_carrier()?


  i'll try to keep this (relatively) short as there may be a simple
answer to this, or it could just be a stupid question -- sort of
related to previous question (thank you, florian).

  currently messing with networking device involving FPGA and some
quad-port transceivers, and noticed that, when one unplugs or plugs a
device into one of the ports, there is no change in the contents of
the corresponding sysfs files /sys/class/net/<ifname>/carrier (or
operstate, for that matter, which might be related to this as well).
doing this with a "regular" port on my linux laptop certainly
confirmed that the carrier file would switch between 0 and 1, and
operstate would switch between up and down, so i know what behaviour i
was *expecting* if things were ostensibly working properly.

  long story short, i pawed through the driver code only to stumble
over this in the ethernet driver for the device:

  static const struct net_device_ops netdev_netdev_ops = {
  ... snip ...
        .ndo_change_carrier     = netdev_change_carrier,
  ... snip ...
  };

and

  static int
  netdev_change_carrier(struct net_device *dev, bool new_carrier)
  {
        if (new_carrier)
                netif_carrier_on(dev);
        else
                netif_carrier_off(dev);
        return 0;
  }

as i mentioned before, i am really new to kernel networking code, so i
did a quick search and found this in netdevice.h:

* int (*ndo_change_carrier)(struct net_device *dev, bool new_carrier);
 *      Called to change device carrier. Soft-devices (like dummy, team, etc)
 *      which do not represent real hardware may define this to allow their
 *      userspace components to manage their virtual carrier state. Devices
 *      that determine carrier state from physical hardware properties (eg
 *      network cables) or protocol-dependent mechanisms (eg
 *      USB_CDC_NOTIFY_NETWORK_CONNECTION) should NOT implement this function.
 *

although i still don't fully understand the purpose of that field, it
makes me *very* nervous to read that that routine is for "soft"
devices, and ***not*** for devices that attempt to determine carrier
state from physical hardware properties. i searched the kernel code
base for other drivers that set that field, and found only what is
mentioned in that comment -- dummy.c, of_dummy_mac.c and team.c.

  the testers for this unit are complaining that they are somehow not
being notified when they plug and unplug devices from the ports -- is
this why? what would be the purpose of assigning a routine to that
field? as i read it (and i could be wrong), my impression is that you
can have the driver *either* determine the carrier state from physical
properties, *or* allow userspace control, but not both, is that
correct?

  i'm about to ask the original authors why they did the above, but
i'd like to feel that it's not a stupid question if there's something
really clever going on here. is this just a development debugging
feature that would normally be removed at production? or what?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                  http://crashcourse.ca/dokuwiki

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Powered by blists - more mailing lists