Linux系統網路裝置啟動和禁止“ifconfig eth0 up/down”命令的跟蹤
前面文章講了Linux系統的ethtool框架的一些東西,是從使用者空間可以直觀認識到的地方入手。同樣,本文從Linux系統絕大部分人都熟悉的“ifconfig eth0 up”命令來跟蹤一下此命令在核心中的發生了什麼事情。由於ifconfig啟動(up)和禁止(down)網路裝置很相似,就放到一起講了。
首先從ifconfig的原始碼入手,我下載的原始碼地址是http://www.tazenda.demon.co.uk/phil/net-tools/。這個網站上還有大量很有用的工具的原始碼,原始碼分佈符合Linux的系統目錄,有興趣的可以去看看。
在我們輸入up或down時,對應的程式碼如下:
main() { if (!strcmp(*spp, "up")) { goterr |= set_flag(ifr.ifr_name, (IFF_UP | IFF_RUNNING)); spp++; continue; } if (!strcmp(*spp, "down")) { goterr |= clr_flag(ifr.ifr_name, IFF_UP); spp++; continue; } }
很簡單,就是根據使用者的輸入來標誌IFF_UP參考。當up時,使用set_flag置位IFF_UP和IFF_RUNNING,當down時,使用clr_flag清除IFF_UP。Linux的這種思想值得學習,其實對於核心來講,真的就是通過IFF_UP標誌來判斷網絡卡的使能和禁止的。
來看設定標誌的set_flag函式:
static int set_flag(char *ifname, short flag) { struct ifreq ifr; safe_strncpy(ifr.ifr_name, ifname, IFNAMSIZ); if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0) { fprintf(stderr, _("%s: unknown interface: %s\n"), ifname, strerror(errno)); return (-1); } safe_strncpy(ifr.ifr_name, ifname, IFNAMSIZ); ifr.ifr_flags |= flag; if (ioctl(skfd, SIOCSIFFLAGS, &ifr) < 0) { perror("SIOCSIFFLAGS"); return -1; } return (0); }
以及清除標誌的clr_flag函式:
static int clr_flag(char *ifname, short flag) { struct ifreq ifr; int fd; if (strchr(ifname, ':')) { /* This is a v4 alias interface. Downing it via a socket for another AF may have bad consequences. */ fd = get_socket_for_af(AF_INET); if (fd < 0) { fprintf(stderr, _("No support for INET on this system.\n")); return -1; } } else fd = skfd; safe_strncpy(ifr.ifr_name, ifname, IFNAMSIZ); if (ioctl(fd, SIOCGIFFLAGS, &ifr) < 0) { fprintf(stderr, _("%s: unknown interface: %s\n"), ifname, strerror(errno)); return -1; } safe_strncpy(ifr.ifr_name, ifname, IFNAMSIZ); ifr.ifr_flags &= ~flag; if (ioctl(fd, SIOCSIFFLAGS, &ifr) < 0) { perror("SIOCSIFFLAGS"); return -1; } return (0); }
觀察這兩個函式,最後都是使用SIOCSIFFLAGS命令和核心互動。我們找到這個命令的使用地方,它位於net/core/dev.c檔案,如下:
int dev_ioctl(struct net *net, unsigned int cmd, void __user *arg)
{
case SIOCSIFFLAGS:
case SIOCSIFMETRIC:
case SIOCSIFMTU:
case SIOCSIFMAP:
case SIOCSIFHWADDR:
case SIOCSIFSLAVE:
case SIOCADDMULTI:
case SIOCDELMULTI:
case SIOCSIFHWBROADCAST:
case SIOCSIFTXQLEN:
case SIOCSMIIREG:
case SIOCBONDENSLAVE:
case SIOCBONDRELEASE:
case SIOCBONDSETHWADDR:
case SIOCBONDCHANGEACTIVE:
case SIOCBRADDIF:
case SIOCBRDELIF:
case SIOCSHWTSTAMP:
if (!capable(CAP_NET_ADMIN))
return -EPERM;
/* fall through */
case SIOCBONDSLAVEINFOQUERY:
case SIOCBONDINFOQUERY:
dev_load(net, ifr.ifr_name);
rtnl_lock();
ret = dev_ifsioc(net, &ifr, cmd);
rtnl_unlock();
return ret;
}
SIOCSIFFLAGS會呼叫到dev_ifsioc函式:
static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
{
switch (cmd) {
case SIOCSIFFLAGS: /* Set interface flags */
return dev_change_flags(dev, ifr->ifr_flags);
}
繼續跟進dev_change_flags函式:
int dev_change_flags(struct net_device *dev, unsigned flags)
{
int ret, changes;
int old_flags = dev->flags;
ret = __dev_change_flags(dev, flags); // 開啟裝置
if (ret < 0)
return ret;
changes = old_flags ^ dev->flags;
if (changes)
rtmsg_ifinfo(RTM_NEWLINK, dev, changes); // 暫未了解
__dev_notify_flags(dev, old_flags); // 向通道鏈netdev_chain發出通知
return ret;
}
真正幹活的是__dev_change_flags函式:
int __dev_change_flags(struct net_device *dev, unsigned int flags)
{
if ((old_flags ^ flags) & IFF_UP) { /* Bit is different ? */
ret = ((old_flags & IFF_UP) ? __dev_close : __dev_open)(dev);
}
根據標誌選擇開啟裝置__dev_open或關閉__dev_close。在同一檔案還有dev_open或dev_close,我發現它們使用了EXPORT_SYMBOL匯出,供給其它模組使用,但在這裡,是使用了__dev_XX函式的。
開啟函式如下:
static int __dev_open(struct net_device *dev)
{
const struct net_device_ops *ops = dev->netdev_ops;
int ret;
ASSERT_RTNL();
/*
* Is it even present?
*/
if (!netif_device_present(dev))
return -ENODEV;
ret = call_netdevice_notifiers(NETDEV_PRE_UP, dev);
ret = notifier_to_errno(ret);
if (ret)
return ret;
/*
* Call device private open method
*/
set_bit(__LINK_STATE_START, &dev->state);
if (ops->ndo_validate_addr)
ret = ops->ndo_validate_addr(dev);
if (!ret && ops->ndo_open)
ret = ops->ndo_open(dev);
/*
* If it went open OK then:
*/
if (ret)
clear_bit(__LINK_STATE_START, &dev->state);
return ret;
}
在真正呼叫具體驅動的介面前,先發NETDEV_PRE_UP給到通知鏈,再置__LINK_STATE_START,然後才呼叫驅動的ndo_open介面,最後需要清除__LINK_STATE_START標誌。
關閉函式如下:
static int __dev_close(struct net_device *dev)
{
const struct net_device_ops *ops = dev->netdev_ops;
ASSERT_RTNL();
might_sleep();
/*
* Tell people we are going down, so that they can
* prepare to death, when device is still operating.
*/
call_netdevice_notifiers(NETDEV_GOING_DOWN, dev);
clear_bit(__LINK_STATE_START, &dev->state);
/* Synchronize to scheduled poll. We cannot touch poll list,
* it can be even on different cpu. So just clear netif_running().
*
* dev->stop() will invoke napi_disable() on all of it's
* napi_struct instances on this device.
*/
smp_mb__after_clear_bit(); /* Commit netif_running(). */
dev_deactivate(dev);
/*
* Call the device specific close. This cannot fail.
* Only if device is UP
*
* We allow it to be called even after a DETACH hot-plug
* event.
*/
if (ops->ndo_stop)
ops->ndo_stop(dev);
/*
* Device is now down.
*/
dev->flags &= ~IFF_UP;
return 0;
}
在真正呼叫具體驅動的介面前,先發NETDEV_GOING_DOWN給到通知鏈,表示網路裝置準備掛了,再清除__LINK_STATE_START標誌,然後才呼叫驅動的ndo_stop介面,最後需要清除IFF_UP。
經過核心的層層結構,條條框框,終於到了具體的驅動了,上面的函式使用的介面實際上是net_device_ops結構體的函式指標,還是以igb驅動為例,賦值如下:
static const struct net_device_ops igb_netdev_ops = {
.ndo_open = igb_open,
.ndo_stop = igb_close,
.ndo_start_xmit = igb_xmit_frame_adv,
.ndo_get_stats64 = igb_get_stats64,
.ndo_set_rx_mode = igb_set_rx_mode,
.ndo_set_multicast_list = igb_set_rx_mode,
.ndo_set_mac_address = igb_set_mac,
.ndo_change_mtu = igb_change_mtu,
.ndo_do_ioctl = igb_ioctl,
.ndo_tx_timeout = igb_tx_timeout,
.ndo_validate_addr = eth_validate_addr,
.ndo_vlan_rx_register = igb_vlan_rx_register,
.ndo_vlan_rx_add_vid = igb_vlan_rx_add_vid,
.ndo_vlan_rx_kill_vid = igb_vlan_rx_kill_vid,
.ndo_set_vf_mac = igb_ndo_set_vf_mac,
.ndo_set_vf_vlan = igb_ndo_set_vf_vlan,
.ndo_set_vf_tx_rate = igb_ndo_set_vf_bw,
.ndo_get_vf_config = igb_ndo_get_vf_config,
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = igb_netpoll,
#endif
};
我們看到最開始的2個函式就是開啟和關閉。在igb_probe函式對igb_netdev_ops進行賦值:
netdev->netdev_ops = &igb_netdev_ops;
至此,整個過程分析完畢。文中涉及到通知鏈,網路裝置通知鏈netdev_chain,這個還沒研究過,這裡簡單列一下:
// 宣告通知連結串列
static RAW_NOTIFIER_HEAD(netdev_chain);
//註冊
int register_netdevice_notifier(struct notifier_block *nb)
{
raw_notifier_chain_register(&netdev_chain, nb);
}
登出:
int unregister_netdevice_notifier(struct notifier_block *nb)
{
int err;
err = raw_notifier_chain_unregister(&netdev_chain, nb);
}
31號的PS:
寫完後想一想,感覺沒到分析徹底,因為到具體的驅動後幹了些什麼還沒跟蹤,於是又花了點時間跟蹤一下。我跟蹤的是ti的網絡卡驅動,主要實現程式碼在cpsw.c檔案,在http://lxr.oss.org.cn/source/drivers/net/ethernet/ti/?v=3.17可以找到。下面列出啟動網絡卡時的過程的重要函式呼叫:
> cpsw_ndo_open
> cpsw_slave_open
> phy_connect (傳遞cpsw_adjust_link)
> phy_connect_direct (PHY_READY)
> phy_prepare_link (賦值cpsw_adjust_link為adjust_link)
> phy_start_machine
> phy_start (PHY_READY變成PHY_UP)
phy_start之後進入了phy驅動重要的狀態判斷函式phy_state_machine,phy驅動有一個工作佇列就是呼叫這個函式的,這個函式判斷了網路各種狀態:PHY_DOWN、PHY_UPPHY_AN、PHY_NOLINK,等,並做出對應的動作。我們設定了PHY_UP,則函式過程如下:phy_state_machine
> phy_start_aneg
> config_aneg
> genphy_config_aneg(實際上是這個函式,由phy驅動賦值的)
到了genphy_config_aneg這個函式,就是直接和phy晶片打交道了,讀phy暫存器、寫phy暫存器。預設情況下會進行自動協商(其實就是寫phy的第0個暫存器),當然,如果不是,即phy_device成員變數autoneg是AUTONEG_DISABLE,則會強制設定指定的速率、雙工模式。
至此,就不再繼續分析、跟蹤了。
2015.3.30 李遲