【嵌入式面试】嵌入式面试Linux驱动篇

已于 2025-07-28 12:16:35 修改
阅读量421 收藏 7
点赞数 9
CC 4.0 BY-SA版权
分类专栏： 嵌入式面试 文章标签： 面试 linux
于 2025-07-28 11:47:32 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/CUI9015/article/details/149712712

💌 所属专栏：【嵌入式面试】
😀 作  者：兰舟比特 🐾
🚀 个人简介：热爱开源系统与嵌入式技术，专注 Linux、网络通信、编程技巧、面试总结与软件工具分享，持续输出实用干货！
💡 欢迎大家：这里是兰舟比特的技术小站，喜欢的话请点赞、收藏、评论三连击！有问题欢迎留言交流😘😘😘

🐧 嵌入式面试Linux驱动篇：15道高频题深度解析，从字符设备到设备树，一文通关！

在物联网、智能硬件、工业控制等领域，Linux设备驱动开发是嵌入式系统的核心技术之一。无论是智能摄像头、工业网关还是车载系统，都离不开稳定高效的设备驱动支持。

作为嵌入式Linux开发中的"硬核"方向，设备驱动岗位面试以其技术深度和广度著称，往往成为求职路上的"拦路虎"。本文将带你系统梳理Linux驱动开发面试中的高频考点，通过15道经典问题的深度解析，助你轻松应对技术面，拿下心仪的Offer！

📌 为什么Linux驱动面试这么难？

与普通应用开发不同，Linux驱动开发需要：

  • 深入理解Linux内核架构
  • 精通硬件交互原理
  • 掌握内核编程规范
  • 具备底层调试能力

面试官通过这些问题，主要考察：

  • 内核机制的理解深度
  • 硬件与软件的衔接能力
  • 并发与同步问题的处理经验
  • 调试与问题解决的实际能力

🔍 一、Linux内核基础（必考！）

1️⃣ 面试题：用户空间与内核空间有什么区别？为什么要有这种区分？

💡 面试官考察点：
  • 对Linux内存管理的基本理解
  • 安全性与稳定性意识
  • 系统架构认知
✅ 正确答案：

区别：

特性用户空间内核空间
访问权限Ring 3（最低）Ring 0（最高）
内存范围0x00000000~0xBFFFFFFF0xC0000000~0xFFFFFFFF
可执行指令普通指令特权指令
崩溃影响仅影响单个进程可能导致系统崩溃

设计原因：

  • 安全性：防止用户程序直接访问硬件或关键数据
  • 稳定性：隔离用户程序错误，避免影响整个系统
  • 资源管理：内核统一管理硬件资源，提供抽象接口

💡 加分回答：在嵌入式系统中，这种区分尤为重要。例如，工业设备中一个失控的用户程序不应导致整个控制系统崩溃。通过系统调用（如ioctl）实现安全的用户-内核通信是驱动开发的关键。

2️⃣ 面试题：系统调用是如何从用户空间进入内核空间的？

💡 面试官考察点：
  • 对Linux系统调用机制的理解
  • 硬件与软件交互认知
  • 底层执行流程掌握
✅ 正确答案：

执行流程：

  1. 用户程序调用glibc封装的系统调用（如open()）
  2. glibc设置系统调用号到寄存器（如eax）
  3. 执行软中断指令（int 0x80）或syscall指令
  4. CPU切换到内核态，跳转到中断处理程序
  5. 内核根据系统调用号查找sys_call_table
  6. 执行对应的系统调用处理函数（如sys_open）
  7. 返回用户空间，恢复执行

关键数据结构：

// 系统调用表（以x86为例）
extern const sys_call_ptr_t sys_call_table[];

// 系统调用实现
asmlinkage long sys_open(const char __user *filename, int flags, umode_t mode);

💡 加分回答：在ARM架构中，通常使用SVC指令触发系统调用。现代CPU还支持更快的syscall/sysret指令。理解这一过程有助于调试系统调用相关问题，如使用strace跟踪系统调用。

⚙️ 二、设备驱动模型

3️⃣ 面试题：Linux设备驱动模型的三大核心概念是什么？

💡 面试官考察点：
  • 对Linux设备模型的整体把握
  • 模块化设计思维
  • 驱动架构理解
✅ 正确答案：

Linux设备驱动模型的三大核心概念：

  1. 设备（device）：

    • 代表物理或虚拟硬件
    • struct device 是核心数据结构
    • 通过总线连接到系统

  2. 总线（bus）：

    • 设备与驱动的连接媒介
    • 实现设备与驱动的匹配
    • 常见总线：platform、PCI、USB、I2C、SPI

  3. 驱动（driver）：

    • 控制设备的软件
    • struct device_driver 是核心数据结构
    • 通过总线与设备匹配

关系图：

+--------+      +-------+      +---------+
| Device | <--> |  Bus  | <--> | Driver  |
+--------+      +-------+      +---------+

💡 加分回答：设备模型实现了"驱动与设备分离"的设计思想，使驱动可以独立于具体硬件。在嵌入式开发中，platform总线和设备树（Device Tree）是实现这一思想的关键技术，极大提高了代码的可移植性。

4️⃣ 面试题：platform总线的作用是什么？请说明其工作流程

💡 面试官考察点：
  • 对platform机制的理解
  • 设备与驱动分离的实际应用
  • 嵌入式系统架构认知
✅ 正确答案：

作用：

  • 实现SoC内部集成设备（如UART、I2C控制器）的驱动与设备分离
  • 避免直接在内核中硬编码设备信息
  • 提高驱动的可移植性和复用性

工作流程：

  1. 设备注册：

    static struct platform_device my_device = {
    .name = "my_device",
    .id = -1,
    .resource = my_resources,
    .num_resources = ARRAY_SIZE(my_resources),
};
platform_device_register(&my_device);

  2. 驱动注册：

    static struct platform_driver my_driver = {
    .probe = my_probe,
    .remove = my_remove,
    .driver = {
        .name = "my_device",
        .of_match_table = my_of_match,
    },
};
platform_driver_register(&my_driver);

  3. 匹配过程：

    • 内核比较platform_device.name与platform_driver.driver.name
    • 或通过设备树of_match_table进行匹配
    • 匹配成功后调用.probe函数

  4. 资源获取：

    static int my_probe(struct platform_device *pdev) {
    struct resource *res;
    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    void __iomem *base = devm_ioremap_resource(&pdev->dev, res);
    // ...
}

💡 加分回答：在现代嵌入式Linux中，设备信息通常通过设备树（.dts文件）描述，内核自动创建platform_device，无需在代码中硬编码。这种机制使同一驱动可以支持不同硬件平台，只需修改设备树即可。

🖥️ 三、字符设备驱动（必会！）

5️⃣ 面试题：请简述字符设备驱动的注册流程

💡 面试官考察点：
  • 字符设备驱动的基本实现能力
  • 内核API熟悉程度
  • 代码组织能力
✅ 正确答案：

字符设备驱动注册标准流程：

static int major; // 主设备号
static struct cdev my_cdev;
static struct class *my_class;

// 1. 分配/注册设备号
static int __init my_driver_init(void) {
    // 动态分配设备号
    alloc_chrdev_region(&devno, 0, 1, "my_device");
    major = MAJOR(devno);
    
    // 2. 初始化cdev
    cdev_init(&my_cdev, &my_fops);
    my_cdev.owner = THIS_MODULE;
    cdev_add(&my_cdev, devno, 1);
    
    // 3. 创建设备节点
    my_class = class_create(THIS_MODULE, "my_class");
    device_create(my_class, NULL, devno, NULL, "my_device");
    
    return 0;
}

// 4. 定义文件操作
static const struct file_operations my_fops = {
    .owner = THIS_MODULE,
    .open = my_open,
    .read = my_read,
    .write = my_write,
    .release = my_release,
};

// 5. 清理
static void __exit my_driver_exit(void) {
    device_destroy(my_class, MKDEV(major, 0));
    class_destroy(my_class);
    cdev_del(&my_cdev);
    unregister_chrdev_region(MKDEV(major, 0), 1);
}

💡 加分回答：在较新内核中，推荐使用devm_*系列资源管理函数（如devm_cdev_add），它们会自动管理资源释放，避免资源泄漏。另外，设备树会自动创建设备节点，无需手动调用device_create。

6️⃣ 面试题：open、read、write系统调用在内核中是如何处理的？

💡 面试官考察点：
  • 系统调用到驱动接口的映射
  • 文件操作流程理解
  • 驱动接口设计能力
✅ 正确答案：

处理流程：

  1. 系统调用入口：

    • 用户调用open("/dev/mydev", O_RDWR)
    • glibc封装后触发系统调用

  2. VFS层处理：

    • 内核通过sys_open找到对应inode
    • 根据inode找到file_operations
    • 调用f_op->open（即驱动中的.open方法）

  3. 驱动层处理：

    static int my_open(struct inode *inode, struct file *filp) {
    // 获取设备私有数据
    struct my_dev *dev = container_of(inode->i_cdev, struct my_dev, cdev);
    filp->private_data = dev;
    
    // 初始化硬件
    // ...
    
    return 0;
}

  4. 数据传输：

    • read/write调用类似，通过copy_to_user/copy_from_user在用户空间和内核空间传输数据
    static ssize_t my_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos) {
    struct my_dev *dev = filp->private_data;
    if (copy_to_user(buf, dev->buffer, count))
        return -EFAULT;
    return count;
}

💡 加分回答：在嵌入式系统中，需特别注意copy_to_user/copy_from_user的使用：

  • 它们可能失败，必须检查返回值
  • 可能引起进程休眠，不能在中断上下文或原子上下文中调用
  • 对于DMA操作，应使用get_user_pages获取用户空间物理地址，避免数据拷贝

🌐 四、设备树（Device Tree）

7️⃣ 面试题：设备树是什么？为什么要用设备树？

💡 面试官考察点：
  • 对现代Linux启动流程的理解
  • 硬件抽象能力
  • 嵌入式系统架构演变认知
✅ 正确答案：

设备树（Device Tree）：

  • 一种描述硬件配置的数据结构
  • 以.dts（源文件）和.dtb（二进制）格式存在
  • 在启动时由bootloader传递给内核

作用：

  • 描述SoC、外设及其连接关系
  • 包含寄存器地址、中断号、时钟频率等硬件信息
  • 使同一内核可支持多种硬件平台

为什么需要设备树：

  1. 历史问题：早期ARM Linux内核针对每种硬件都有单独分支，维护困难
  2. 代码复用：设备树将硬件描述与驱动代码分离
  3. 灵活性：无需重新编译内核即可支持新硬件
  4. 标准化：统一了不同架构的硬件描述方式

设备树片段示例：

/ {
    soc {
        serial@1c28000 {
            compatible = "allwinner,sun8i-h3-uart";
            reg = <0x01c28000 0x400>;
            interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&ccu CLK_BUS_UART0>, <&ccu CLK_UART0>;
            clock-names = "apb", "mod";
            status = "okay";
        };
    };
};

💡 加分回答：设备树是嵌入式Linux发展的重要里程碑。在驱动开发中，我们通过of_match_table匹配设备树节点，使用of_property_read_*系列函数读取属性。这种机制使驱动更加通用，只需修改设备树即可适配不同硬件。

8️⃣ 面试题：如何在驱动中获取设备树中的属性值？

💡 面试官考察点：
  • 设备树API实际应用能力
  • 驱动与设备树交互经验
  • 代码实现细节
✅ 正确答案：

常用API获取设备树属性：

static int my_probe(struct platform_device *pdev)
{
    struct device_node *np = pdev->dev.of_node;
    u32 value;
    const char *str;
    struct resource res;
    
    // 1. 读取整数值
    if (of_property_read_u32(np, "reg-value", &value)) {
        dev_err(&pdev->dev, "Failed to get reg-value\n");
        return -EINVAL;
    }
    
    // 2. 读取字符串
    if (of_property_read_string(np, "compatible", &str)) {
        dev_err(&pdev->dev, "Failed to get compatible\n");
        return -EINVAL;
    }
    
    // 3. 获取寄存器地址
    if (of_address_to_resource(np, 0, &res)) {
        dev_err(&pdev->dev, "Failed to get address\n");
        return -EINVAL;
    }
    void __iomem *base = devm_ioremap_resource(&pdev->dev, &res);
    
    // 4. 获取中断号
    int irq = platform_get_irq(pdev, 0);
    
    // 5. 获取GPIO
    int gpio = of_get_named_gpio(np, "my-gpio", 0);
    
    return 0;
}

匹配表定义：

static const struct of_device_id my_of_match[] = {
    { .compatible = "vendor,my-device", },
    { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, my_of_match);

static struct platform_driver my_driver = {
    .probe = my_probe,
    .driver = {
        .name = "my_driver",
        .of_match_table = my_of_match,
    },
};

💡 加分回答：在实际开发中，应使用devm_*系列资源管理函数（如devm_ioremap_resource），它们会在设备移除时自动释放资源。另外，对于复杂的设备树属性，可使用of_parse_phandle处理节点引用。

⚡ 五、中断处理

9️⃣ 面试题：Linux中断处理的上半部和下半部有什么区别？常用下半部机制有哪些？

💡 面试官考察点：
  • 中断处理机制理解
  • 实时性与效率权衡
  • 并发问题处理能力
✅ 正确答案：

上半部（Top Half）：

  • 特点：快速响应，不能休眠，执行时间短
  • 执行环境：中断上下文
  • 工作：读取硬件状态，清除中断标志，触发下半部

下半部（Bottom Half）：

  • 特点：可休眠，可被调度，执行时间较长
  • 执行环境：进程上下文或软中断上下文
  • 工作：数据处理、唤醒任务等耗时操作

常用下半部机制：

机制特点适用场景
软中断（softirq）高效、不可抢占网络、块设备等高性能场景
tasklet基于软中断，简单易用大多数中断处理场景
工作队列（workqueue）运行在进程上下文，可休眠需要睡眠或阻塞的操作
线程化中断将中断处理转为内核线程实时性要求高的场景

示例代码：

// 使用tasklet
static void my_tasklet_handler(unsigned long data) {
    struct my_dev *dev = (struct my_dev *)data;
    // 处理中断数据
}

static DECLARE_TASKLET(my_tasklet, my_tasklet_handler, 0);

static irqreturn_t my_irq_handler(int irq, void *dev_id) {
    struct my_dev *dev = dev_id;
    // 读取状态、清除中断
    tasklet_schedule(&my_tasklet);
    return IRQ_HANDLED;
}

// 使用工作队列
static void my_work_handler(struct work_struct *work) {
    struct my_dev *dev = container_of(work, struct my_dev, work);
    // 处理中断数据
}

static irqreturn_t my_irq_handler(int irq, void *dev_id) {
    struct my_dev *dev = dev_id;
    // 读取状态、清除中断
    schedule_work(&dev->work);
    return IRQ_HANDLED;
}

💡 加分回答：在嵌入式系统中，中断处理直接影响系统实时性。对于高频率中断（如串口接收），应尽量减少上半部工作量；对于需要睡眠的操作（如访问I2C总线），必须使用工作队列。在实时Linux中，还可使用线程化中断提高确定性。

🔟 面试题：编写一个中断处理程序，需要注意哪些问题？

💡 面试官考察点：
  • 中断编程规范
  • 边界情况处理
  • 实际开发经验
✅ 正确答案：

编写中断处理程序的注意事项：

  1. 快速执行：

    • 上半部应尽量简短
    • 耗时操作移到下半部

  2. 不可休眠：

    • 不能调用可能休眠的函数（如kmalloc带GFP_KERNEL）
    • 不能获取可能引起休眠的锁

  3. 共享资源保护：

    • 使用自旋锁保护共享数据
    • 中断上下文使用spin_lock_irqsave/spin_unlock_irqrestore

  4. 返回值处理：

    • 正确返回IRQ_HANDLED或IRQ_NONE
    • 共享中断需判断是否本设备触发

  5. 中断嵌套：

    • 默认情况下，处理中断时会禁用同级中断
    • 如需允许嵌套，注册时使用IRQF_SHARED和IRQF_NOAUTOEN

示例代码：

static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
    struct my_dev *dev = dev_id;
    unsigned long flags;
    u32 status;
    
    // 1. 读取中断状态寄存器
    status = ioread32(dev->base + INT_STATUS_REG);
    
    // 2. 检查是否本设备中断
    if (!(status & MY_DEVICE_INT))
        return IRQ_NONE;
    
    // 3. 清除中断标志
    iowrite32(status, dev->base + INT_STATUS_REG);
    
    // 4. 保护共享数据
    spin_lock_irqsave(&dev->lock, flags);
    dev->irq_count++;
    spin_unlock_irqrestore(&dev->lock, flags);
    
    // 5. 触发下半部
    tasklet_schedule(&dev->irq_tasklet);
    
    return IRQ_HANDLED;
}

💡 加分回答：在嵌入式系统中，还需注意：

  • 中断优先级配置（通过GIC等中断控制器）
  • 对于共享中断线，确保request_irq时使用IRQF_SHARED
  • 在SoC级，检查中断是否已使能、是否配置了正确的触发方式
  • 使用devm_request_irq自动管理资源

🔒 六、内核同步机制

1️⃣1️⃣ 面试题：Linux内核中有哪些常用的同步机制？各自适用场景是什么？

💡 面试官考察点：
  • 并发问题理解
  • 同步机制掌握程度
  • 实际应用场景判断
✅ 正确答案：

Linux内核常用同步机制对比：

机制特点适用场景
原子操作不可分割，最轻量简单计数器、标志位
位操作操作单个位设备状态标志
自旋锁忙等待，不可休眠短时间临界区（中断安全）
信号量可休眠，计数较长时间临界区
互斥锁信号量特例，只能为1互斥访问
RCU读不阻塞，写开销大读多写少场景
完成量线程同步一个线程等待另一个完成

典型使用示例：

  1. 原子操作：

    static atomic_t irq_count = ATOMIC_INIT(0);
atomic_inc(&irq_count);

  2. 自旋锁：

    spinlock_t lock;
spin_lock_init(&lock);

spin_lock(&lock);
// 操作共享数据
spin_unlock(&lock);

  3. 互斥锁：

    struct mutex lock;
mutex_init(&lock);

mutex_lock(&lock);
// 操作共享数据
mutex_unlock(&lock);

💡 加分回答：在嵌入式驱动开发中：

  • 中断上下文只能使用自旋锁或原子操作
  • 对于短时间临界区（<20条指令），自旋锁效率更高
  • 互斥锁适合可能休眠的场景（如访问用户空间内存）
  • RCU在设备模型和网络子系统中广泛应用，适合只读频繁的场景

1️⃣2️⃣ 面试题：自旋锁和互斥锁有什么区别？何时应该使用自旋锁？

💡 面试官考察点：
  • 同步机制深入理解
  • 性能与安全权衡
  • 实际开发经验
✅ 正确答案：

区别：

特性自旋锁互斥锁
等待方式忙等待（CPU循环）进入睡眠
上下文限制可用于中断上下文仅用于进程上下文
适用时间短时间临界区较长时间临界区
死锁风险低（通常不嵌套）高（可能嵌套）
开销小（无上下文切换）大（涉及调度）

何时使用自旋锁：

  1. 临界区执行时间很短（通常<20条指令）
  2. 可能在中断处理程序中使用
  3. 不会进入休眠（如不能调用copy_to_user）
  4. 多处理器系统中，等待时间可能小于上下文切换开销

典型场景：

  • 中断处理中的共享数据保护
  • 高频计数器更新
  • 硬件寄存器操作

使用示例：

spinlock_t lock;
spin_lock_init(&lock);

// 中断上下文或原子上下文
spin_lock(&lock);
// 快速操作共享数据
spin_unlock(&lock);

// 带中断保存的自旋锁（在中断处理中使用）
unsigned long flags;
spin_lock_irqsave(&lock, flags);
// 操作共享数据
spin_unlock_irqrestore(&lock, flags);

💡 加分回答：在嵌入式系统中，由于资源有限，自旋锁的使用需格外谨慎：

  • 单核系统中，自旋锁会禁用本地中断，防止死锁
  • 避免在自旋锁保护的临界区内调用可能休眠的函数
  • 对于可能长时间持有的锁，应使用互斥锁
  • 使用spin_trylock避免死锁风险

🧪 七、实战面试题

1️⃣3️⃣ 面试题：实现一个简单的字符设备驱动，支持read/write和ioctl

💡 面试官考察点：
  • 驱动框架搭建能力
  • 核心API掌握程度
  • 代码规范与完整性
✅ 正确答案：
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/uaccess.h>
#include <linux/slab.h>

#define DEVICE_NAME "mychardev"
#define MY_MAGIC 'k'
#define MY_IOCTL_SET_VALUE _IOW(MY_MAGIC, 0, int)
#define MY_IOCTL_GET_VALUE _IOR(MY_MAGIC, 1, int)

struct my_device {
    char *buffer;
    size_t size;
    int value;
    struct cdev cdev;
    spinlock_t lock;
};

static dev_t dev_num;
static struct class *my_class;
static struct my_device *my_dev;

static int my_open(struct inode *inode, struct file *filp)
{
    filp->private_data = container_of(inode->i_cdev, struct my_device, cdev);
    return 0;
}

static ssize_t my_read(struct file *filp, char __user *buf, size_t count, loff_t *f_pos)
{
    struct my_device *dev = filp->private_data;
    size_t to_read;
    unsigned long flags;
    
    if (*f_pos >= dev->size)
        return 0;
    
    to_read = min(count, dev->size - *f_pos);
    
    spin_lock_irqsave(&dev->lock, flags);
    if (copy_to_user(buf, dev->buffer + *f_pos, to_read)) {
        spin_unlock_irqrestore(&dev->lock, flags);
        return -EFAULT;
    }
    spin_unlock_irqrestore(&dev->lock, flags);
    
    *f_pos += to_read;
    return to_read;
}

static ssize_t my_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos)
{
    struct my_device *dev = filp->private_data;
    size_t to_write;
    unsigned long flags;
    
    if (*f_pos >= dev->size)
        return -ENOSPC;
    
    to_write = min(count, dev->size - *f_pos);
    
    spin_lock_irqsave(&dev->lock, flags);
    if (copy_from_user(dev->buffer + *f_pos, buf, to_write)) {
        spin_unlock_irqrestore(&dev->lock, flags);
        return -EFAULT;
    }
    spin_unlock_irqrestore(&dev->lock, flags);
    
    *f_pos += to_write;
    return to_write;
}

static long my_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
    struct my_device *dev = filp->private_data;
    int val;
    unsigned long flags;
    
    switch (cmd) {
    case MY_IOCTL_SET_VALUE:
        if (copy_from_user(&val, (int __user *)arg, sizeof(int)))
            return -EFAULT;
        
        spin_lock_irqsave(&dev->lock, flags);
        dev->value = val;
        spin_unlock_irqrestore(&dev->lock, flags);
        return 0;
        
    case MY_IOCTL_GET_VALUE:
        spin_lock_irqsave(&dev->lock, flags);
        val = dev->value;
        spin_unlock_irqrestore(&dev->lock, flags);
        
        if (copy_to_user((int __user *)arg, &val, sizeof(int)))
            return -EFAULT;
        return 0;
        
    default:
        return -ENOTTY;
    }
}

static const struct file_operations my_fops = {
    .owner = THIS_MODULE,
    .open = my_open,
    .read = my_read,
    .write = my_write,
    .unlocked_ioctl = my_ioctl,
};

static int __init my_driver_init(void)
{
    int ret;
    
    // 1. 分配设备号
    ret = alloc_chrdev_region(&dev_num, 0, 1, DEVICE_NAME);
    if (ret < 0)
        return ret;
    
    // 2. 分配设备结构
    my_dev = kzalloc(sizeof(*my_dev), GFP_KERNEL);
    if (!my_dev) {
        ret = -ENOMEM;
        goto fail_alloc;
    }
    
    // 3. 初始化设备
    my_dev->size = 4096;
    my_dev->buffer = kzalloc(my_dev->size, GFP_KERNEL);
    if (!my_dev->buffer) {
        ret = -ENOMEM;
        goto fail_buffer;
    }
    spin_lock_init(&my_dev->lock);
    
    // 4. 初始化cdev
    cdev_init(&my_dev->cdev, &my_fops);
    my_dev->cdev.owner = THIS_MODULE;
    ret = cdev_add(&my_dev->cdev, dev_num, 1);
    if (ret < 0)
        goto fail_cdev;
    
    // 5. 创建设备节点
    my_class = class_create(THIS_MODULE, DEVICE_NAME);
    device_create(my_class, NULL, dev_num, NULL, DEVICE_NAME);
    
    printk(KERN_INFO "MyCharDev driver loaded\n");
    return 0;
    
fail_cdev:
    kfree(my_dev->buffer);
fail_buffer:
    kfree(my_dev);
fail_alloc:
    unregister_chrdev_region(dev_num, 1);
    return ret;
}

static void __exit my_driver_exit(void)
{
    device_destroy(my_class, dev_num);
    class_destroy(my_class);
    cdev_del(&my_dev->cdev);
    kfree(my_dev->buffer);
    kfree(my_dev);
    unregister_chrdev_region(dev_num, 1);
    printk(KERN_INFO "MyCharDev driver unloaded\n");
}

module_init(my_driver_init);
module_exit(my_driver_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Your Name");
MODULE_DESCRIPTION("Simple character device driver");

💡 加分回答：

  • 使用devm_*函数自动管理资源（如devm_kzalloc、devm_cdev_add）
  • 添加poll支持实现非阻塞IO
  • 实现mmap支持用户空间直接访问设备内存
  • 添加设备树支持，使驱动更通用
  • 考虑内存对齐和DMA兼容性

1️⃣4️⃣ 面试题：驱动中出现死锁，如何排查和解决？

💡 面试官考察点：
  • 调试能力
  • 并发问题理解
  • 实际问题解决经验
✅ 正确答案：

死锁排查方法：

  1. 启用内核锁调试：

    • 编译内核时启用CONFIG_LOCKDEP
    • 运行时查看/proc/lockdep和/proc/lockdep_stats

  2. 使用ftrace跟踪：

    echo 1 > /sys/kernel/debug/tracing/events/lock/events/enable
cat /sys/kernel/debug/tracing/trace

  3. 添加锁调试信息：

    #define MY_DEBUG_LOCKS
#ifdef MY_DEBUG_LOCKS
#define MY_LOCK(lock) do { \
    printk(KERN_DEBUG "Locking %s:%d\n", __func__, __LINE__); \
    mutex_lock(lock); \
} while (0)
#else
#define MY_LOCK(lock) mutex_lock(lock)
#endif

  4. 使用KASAN检测内存错误：

    • 编译时启用CONFIG_KASAN
    • 检测使用已释放内存等问题

常见死锁场景及解决方案：

场景原因解决方案
锁顺序不一致A→B和B→A的锁获取顺序统一锁获取顺序
递归获取锁重复获取同一互斥锁使用递归锁或重构代码
中断上下文获取锁在中断中获取可能休眠的锁使用自旋锁或拆分操作
长临界区临界区执行时间过长缩短临界区，移到用户空间处理

预防死锁的最佳实践：

  1. 尽量减少锁的使用，考虑无锁设计
  2. 保持一致的锁获取顺序
  3. 避免在持有锁时调用外部函数
  4. 使用mutex_trylock而非mutex_lock
  5. 为锁设置超时（mutex_lock_timeout）
  6. 使用lockdep在开发阶段检测潜在死锁

💡 加分回答：在嵌入式系统中，死锁可能导致设备完全无响应。建议：

  • 在关键驱动中实现看门狗机制
  • 使用CONFIG_DEBUG_RT_MUTEXES检测实时互斥锁问题
  • 对于复杂锁依赖，绘制锁依赖图进行分析
  • 在开发阶段启用所有调试选项，生产环境可关闭

🛠️ 八、I2C/SPI驱动开发

1️⃣5️⃣ 面试题：编写一个I2C设备驱动，需要注意哪些问题？

💡 面试官考察点：
  • 总线驱动理解
  • 硬件交互经验
  • 错误处理能力
✅ 正确答案：

编写I2C设备驱动的注意事项：

  1. 设备树匹配：

    i2c1: i2c@1c2ac00 {
    #address-cells = <1>;
    #size-cells = <0>;
    status = "okay";
    
    my_sensor@68 {
        compatible = "vendor,my-sensor";
        reg = <0x68>;
        interrupt-parent = <&pio>;
        interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
    };
};

  2. 驱动结构：

    static const struct of_device_id my_sensor_of_match[] = {
    { .compatible = "vendor,my-sensor", },
    { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, my_sensor_of_match);

static struct i2c_driver my_sensor_driver = {
    .driver = {
        .name = "my-sensor",
        .of_match_table = my_sensor_of_match,
    },
    .probe = my_sensor_probe,
    .remove = my_sensor_remove,
    .id_table = my_sensor_id,
};

  3. 关键注意事项：

    • I2C传输限制：单次传输通常不超过I2C_ADAPTER_MAX_WRITELEN（通常32-64字节）
    • 错误处理：必须检查i2c_transfer返回值
    • 时序要求：某些设备有严格的时序要求
    • 中断处理：如果使用中断，需正确配置触发方式
    • 电源管理：实现runtime_pm回调

  4. 数据传输示例：

    static int my_sensor_read(struct i2c_client *client, u8 reg, u8 *val)
{
    struct i2c_msg msgs[2];
    u8 buf;
    
    // 写入寄存器地址
    buf = reg;
    msgs[0].addr = client->addr;
    msgs[0].flags = 0;
    msgs[0].len = 1;
    msgs[0].buf = &buf;
    
    // 读取数据
    msgs[1].addr = client->addr;
    msgs[1].flags = I2C_M_RD;
    msgs[1].len = 1;
    msgs[1].buf = val;
    
    if (i2c_transfer(client->adapter, msgs, 2) != 2)
        return -EIO;
    
    return 0;
}

  5. 错误处理：

    • 检查i2c_transfer返回传输成功的消息数
    • 处理NACK、超时等错误
    • 实现重试机制（但避免无限重试）

💡 加分回答：在嵌入式I2C驱动中还需注意：

  • 使用i2c_smbus_read_byte_data等简化函数
  • 对于高频率操作，考虑使用DMA
  • 注意I2C总线速度（标准模式100kHz，快速模式400kHz）
  • 在多设备系统中，避免总线冲突
  • 实现detect函数支持动态设备检测

💡 九、面试准备建议

1. 重点掌握核心知识

  • 必会：字符设备驱动、platform机制、设备树
  • 重点：中断处理、同步机制、内存管理
  • 了解：块设备、网络设备、USB驱动

2. 动手实践

  • 在QEMU或开发板上编译运行内核
  • 亲手编写并测试驱动代码
  • 尝试修改现有驱动解决实际问题
  • 使用printk、ftrace等工具调试

3. 深入理解原理

  • 不仅知道"怎么做"，还要理解"为什么"
  • 阅读内核文档（Documentation/目录）
  • 分析内核源码（drivers/目录）
  • 了解最新内核特性（如Zombie mode、kunit测试）

4. 准备项目案例

  • 准备1-2个完整的驱动开发项目
  • 能详细说明技术难点和解决方案
  • 体现你对驱动架构的深入理解

5. 模拟面试

  • 找朋友互相面试
  • 对着镜子练习表达
  • 记录自己的回答并改进
  • 重点练习手写代码题

📚 结语

Linux设备驱动开发是嵌入式领域的"硬核"技术，掌握它不仅有助于通过面试，更是成为一名高级嵌入式工程师的必经之路。本文梳理的15道高频面试题，覆盖了Linux驱动开发的核心知识点，希望能帮助你在面试中脱颖而出。

记住：驱动开发不仅是写代码，更是理解硬件与软件的桥梁。在面试中，展现你对系统整体的理解和解决实际问题的能力，往往比单纯背题更重要。

🔔 福利：关注我，回复"Linux驱动面试PDF"，可领取本文整理的高清PDF版 + 50道Linux驱动面试题精选！

版权声明：

本文为 兰舟比特 原创内容，如需转载，请注明出处及作者，禁止未经授权的引用或商用。

评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

兰舟比特

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值