if you can tolerate another question on the topic, based on an
earlier post by stephen hemminger, i wrote a userspace program that
opened a netlink socket to track the status changes for an interface,
and i just want to clarify how the up/running status of an interface
is determined, as i think i'm finally getting the hang of this.
as stephen mentioned, ifconfig gets its info (ultimately) from
dev_get_flags() in net/core/dev.c:
unsigned int dev_get_flags(const struct net_device *dev)
{
unsigned int flags;
flags = (dev->flags & ~(IFF_PROMISC |
IFF_ALLMULTI |
IFF_RUNNING |
IFF_LOWER_UP |
IFF_DORMANT)) |
(dev->gflags & (IFF_PROMISC |
IFF_ALLMULTI));
if (netif_running(dev)) {
if (netif_oper_up(dev))
flags |= IFF_RUNNING;
if (netif_carrier_ok(dev))
flags |= IFF_LOWER_UP;
if (netif_dormant(dev))
flags |= IFF_DORMANT;
}
return flags;
}
i don't care (yet) about IFF_{PROMISC,ALLMULTI} so i'll ignore those.
so, as i read it, whether or not the interface is *administratively*
up is read directly from the IFF_UP bit in dev->flags. so far, so
good. on the other hand, all of IFF_{RUNNING,LOWER_UP,DORMANT} are not
read from dev->flags, but instead are "volatile" and are determined
via those function calls.
so i'm guessing that shows the difference between the
administrative and the operational states of an interface -- the
administrative state of "up" is something selected by, say, ifconfig,
and can therefore be stored in the flags field, while the operational
state (running) is volatile and must be determined at each query.
this suggests that volatile flags such as running or dormant have no
value if read from dev->flags -- the code above doesn't even look at
them in that location and instead invokes the respective functions. do
i have that about right, before i crawl further down this rabbit hole?
it's all starting to make sense.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
