Linux 中为什么会存在同一个函数的多重定义？

    ///初始化设备，使得I/O, memory可用，唤醒设备
    ret = pci_enable_device(pci_dev);
    if (ret)
    {
        printk(KERN_ERR "Cannot enable PCI device, aborting.\n");
        goto err_out_free_dev;
    }

int __must_check pci_enable_device(struct pci_dev *dev);

#define	EIO		 5	/* I/O error */
static inline int pci_enable_device(struct pci_dev *dev) { return -EIO; }

查看内核源码

• drivers/pci/pci.c, line 1938

• include/linux/pci.h, line 1159 (as a prototype)

pci_enable_device identifier - Linux source code v5.10.34 - Bootlin Elixir Cross Referencer

Elixir Cross Referencer - pci_enable_device identifier references search for Linux v5.10.34. Documented in drivers/pci/pci.c. Defined as a prototype in include/linux/pci.h. Defined in 2 files as a function: drivers/pci/pci.c... Referenced in 532 files: arch/powerpc/platforms/powermac/feature.c...

https://elixir.bootlin.com/linux/v5.10.34/A/ident/pci_enable_device

/**
 * pci_enable_device - Initialize device before it's used by a driver.
 * @dev: PCI device to be initialized
 *
 * Initialize device before it's used by a driver. Ask low-level code
 * to enable I/O and memory. Wake up the device if it was suspended.
 * Beware, this function can fail.
 *
 * Note we don't actually enable the device many times if we call
 * this function repeatedly (we just increment the count).
 */
int pci_enable_device(struct pci_dev *dev)
{
	return pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO);
}
EXPORT_SYMBOL(pci_enable_device);

原因分析

1. 条件编译机制

• PCI 子系统未启用：如果内核编译时未启用 PCI 子系统（例如在某些嵌入式系统中），那么 pci_enable_device 的实际实现（位于 drivers/pci/pci.c）不会被编译进内核。此时，内联函数的定义（返回 EIO）会作为一个“空实现”或“占位符”，确保代码在未启用 PCI 时仍然可以编译通过。

• 模块化设计：内核的头文件需要为所有可能的配置提供默认行为，即使某些功能未启用。

2. 实际实现与内联函数的优先级

3. 头文件中的内联函数的作用

• 提供默认行为：当 PCI 子系统未启用时，调用 pci_enable_device 会返回 EIO，表示设备无法启用。

• 编译时检查：确保代码在未启用 PCI 时仍然可以编译通过，避免链接错误。

具体实现机制

1. 头文件中的定义

static inline int pci_enable_device(struct pci_dev *dev) { return -EIO; }

• 当 PCI 子系统未启用时，提供一个默认实现。

• 避免未启用 PCI 时调用未定义的函数。

2. 实际实现

int pci_enable_device(struct pci_dev *dev)
{
    return pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO);
}
EXPORT_SYMBOL(pci_enable_device);

3. 条件编译的触发

示例场景

场景 1：PCI 子系统启用

• CONFIG_PCI 被定义。

• drivers/pci/pci.c 被编译，pci_enable_device 的实际实现可用。

• 调用 pci_enable_device 时，实际使用的是 pci.c 中的实现。

场景 2：PCI 子系统未启用

• CONFIG_PCI 未定义。

• drivers/pci/pci.c 未被编译，pci_enable_device 的实际实现不可用。

• 调用 pci_enable_device 时，使用的是头文件中的内联函数，返回 EIO。

总结

• 头文件中的内联函数：提供默认行为，确保代码在 PCI 子系统未启用时仍然可以编译通过。

• 实际实现：当 PCI 子系统启用时，实际使用的是 drivers/pci/pci.c 中的实现。

• 条件编译：通过 CONFIG_PCI 控制是否启用 PCI 子系统，从而决定使用哪种实现。

那 Linux ，是如何通过连接器实现的这个功能呢？

1. 符号的强弱性（Symbol Strength）：
• 强符号（Strong Symbol）：在目标文件中定义的函数或变量，如果有多个强符号定义，链接时会报错。
• 弱符号（Weak Symbol）：在目标文件中定义的函数或变量，如果有多个弱符号定义，链接时会选择其中一个。

2. 内联函数的处理：
• 内联函数在编译时会被直接展开，不会生成独立的符号。
• 如果内联函数没有被展开（例如，编译器决定不内联），则会生成一个弱符号。

3. 链接器的符号解析规则：
• 如果存在强符号和弱符号，链接器会选择强符号。
• 如果只有弱符号，链接器会选择其中一个。

具体实现步骤

1. 编译阶段：
• 当编译一个源文件时，编译器会生成目标文件（.o 文件）。
• 如果源文件中包含内联函数的定义，编译器会尝试将其内联展开。如果无法内联，则会生成一个弱符号。

2. 链接阶段：
• 链接器将所有目标文件和库文件合并，生成最终的可执行文件或内核模块。
• 在链接过程中，链接器会解析所有符号的引用，并根据符号的强弱性选择合适的定义。

示例分析

1. 头文件中的内联函数：

static inline int pci_enable_device(struct pci_dev *dev) { return -EIO; }

• 这个内联函数在编译时会被展开，不会生成独立的符号。
• 如果编译器决定不内联，则会生成一个弱符号。

2. 实际实现：

int pci_enable_device(struct pci_dev *dev)
{
    return pci_enable_device_flags(dev, IORESOURCE_MEM | IORESOURCE_IO);
}
EXPORT_SYMBOL(pci_enable_device);

• 这个函数在 drivers/pci/pci.c 中定义，是一个强符号。

3. 链接过程：
• 如果 CONFIG_PCI 被定义，drivers/pci/pci.c 会被编译，生成的目标文件中包含 pci_enable_device 的强符号。
• 如果 CONFIG_PCI 未定义，drivers/pci/pci.c 不会被编译，目标文件中不包含 pci_enable_device 的强符号。
• 在链接时，如果存在强符号，链接器会选择强符号；如果只有弱符号，链接器会选择弱符号。

具体链接器行为

1. 强符号存在：
• 如果 drivers/pci/pci.o 被链接，其中包含 pci_enable_device 的强符号。
• 链接器会选择这个强符号，忽略头文件中的弱符号。

2. 强符号不存在：
• 如果 drivers/pci/pci.o 未被链接，不包含 pci_enable_device 的强符号。
• 链接器会选择头文件中的弱符号（如果存在）。

总结

• 强符号优先：如果存在强符号，链接器会选择强符号。

• 弱符号备用：如果只有弱符号，链接器会选择弱符号。

• 内联函数处理：内联函数在编译时被展开，不会生成独立的符号；如果无法内联，则生成弱符号。