[英]How does the Linux kernel know which driver functions to call?
I am looking at the 802.11 Realtek driver code from https://github.com/o11s/open80211s/tree/master/drivers/net/wireless/rtl818x/rtl8180 and can't figure out how either the kernel knows which driver functions to call. 我正在从https://github.com/o11s/open80211s/tree/master/drivers/net/wireless/rtl818x/rtl8180查看802.11 Realtek驱动程序代码,无法确定内核如何知道哪个驱动程序起作用呼叫。
For example, how does it know if it needs to call write_grf5101 or rtl8225_write in order to transmit a datagram? 例如,如何知道是否需要调用write_grf5101或rtl8225_write来传输数据报?
From rtl8225.c: 来自rtl8225.c:
static void rtl8225_write(struct ieee80211_hw *dev, u8 addr, u16 data)
{
...
}
From grf5101.c: 从grf5101.c:
static void write_grf5101(struct ieee80211_hw *dev, u8 addr, u32 data)
{
...
}
These two functions are not called by the kernel itself. 内核本身不调用这两个函数。 They are static and reside in corresponding files (probably, chip-specific files). 它们是静态的 ,位于相应的文件(可能是特定于芯片的文件)中。 Also, it seems like they are not used as callbacks in either place. 另外,似乎它们在任何地方都没有用作回调 。
Instead, you may see that, for example, write_grf5101()
is used by grf5101_rf_init()
function in ./drivers/net/wireless/realtek/rtl818x/rtl8180/grf5101.c
file, and that function is set as a callback in rtl818x_rf_ops
structure which in turn, as you might understand, is some sort of like more generic entity within the driver. 相反,你可以看到,例如, write_grf5101()
是使用由grf5101_rf_init()
函数./drivers/net/wireless/realtek/rtl818x/rtl8180/grf5101.c
文件,以及功能 设置为回调中rtl818x_rf_ops
正如您可能理解的那样,结构又像是驱动程序中更通用的某种实体。 For instance, that grf5101_rf_ops
variable (which is of type struct rtl818x_rf_ops
) is set as a callback table by rtl8180_probe()
function in ./drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
. 例如,该grf5101_rf_ops
变量(它是类型的struct rtl818x_rf_ops
)被设定为回调表由rtl8180_probe()
函数./drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c
。 And, finally, the latter rtl8180_probe()
is set as a callback in rtl8180_driver
variable of type struct pci_driver
which, as you might see, is some sort of like an interface maintained by the kernel itself (all PCI devices register themselves with struct pci_driver
). 最后,将后者rtl8180_probe()
设置为 struct pci_driver
类型的rtl8180_driver
变量中的回调 ,如您所见,它有点像内核自身维护的接口(所有PCI设备都向struct pci_driver
注册) 。 The line module_pci_driver(rtl8180_driver);
行module_pci_driver(rtl8180_driver);
below performs such registration in this particular case. 下面在这种特殊情况下执行这种注册。
So, the point is that "the kernel" doesn't know (and probably shouldn't) about such tiny static helper routines. 因此,关键是“内核”不知道(也可能不应该)如此小的静态帮助程序。 Instead, the kernel needs a PCI device description structure which in turn will be used all way round to interface a particular device. 取而代之的是,内核需要一个PCI设备描述结构,该结构随后将被用于与特定设备的接口。 A typical driver, however, may have (and often has) its internal callback structures - often chip-specific (in the case when the driver is designed to serve multiple chips in some sort of like device family) - which in turn will point to chip-specific functions located in the corresponded .c
files. 但是,典型的驱动程序可能具有 (并且经常具有)其内部回调结构-通常是特定于芯片的(在该驱动程序设计为服务某种类型的设备系列中的多个芯片的情况下)-这又将指向特定于芯片的功能位于相应的.c
文件中。 That internal functions may use such helpers (like rtl8225_write()
or write_grf5101()
), and there is nothing to do with kernel in that case. 内部函数可以使用此类帮助程序(如rtl8225_write()
或write_grf5101()
),在这种情况下,与内核无关。 They are just some tiny chip-specific helpers. 他们只是一些特定于芯片的小助手。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.