嵌入式linux面试题整理

Posted on 2025-09-02 Edited on 2025-09-12

嵌入式linux秋招面经整理,驱动开发,BSP相关方向

Q:DDR挂在PS还是PL下面,为什么?如何选择挂在PS还是PL呢?

A:

默认挂载ps,对于zynq的系统来说,ps端启动linux,ddr不可或缺,但是fpga端则不一定
PS端有专门的DDR硬核控制器,性能更好
使用Memory Interface Generator生成软核DDR控制器
只有在PL端需要极大内存带宽时才配置到PL

Q:你做过哪些驱动开发 / 你的驱动是怎么实现的

A:

回答系统级的驱动使能、配置和调试
- 设备树 (DTS):根据硬件手册,配置 reg, interrupts, compatible 属性.
- 内核配置 (Kconfig):通过 menuconfig 确保相关驱动模块被编译.
- 调试验证:用 dmesg, lspci, /dev 节点验证驱动是否成功加载 (probe) 和工作.

Q:硬件的复位电平/延时要求不同,驱动里怎么处理

A:

驱动代码应与硬件参数解耦,通过设备树传递硬件特性
- 在 DTS 中定义 reset-active-low(标志属性)和 reset-delay-ms = <100>;(延时属性).
- 驱动的 probe 函数中,解析这些属性.
- 根据属性值,使用 gpiod_set_value() 控制电平,并用 msleep() 实现延时

Q:如何实现一个中断

A:

注册中断:在 probe 函数中调用 devm_request_irq().
顶半部 (ISR):执行必须快,在中断屏蔽下运行.只做紧急工作:读/写寄存器清中断,拷贝少量数据.调度下半部来处理耗时任务.
底半部 (Workqueue):在正常内核上下文执行,可睡眠.处理复杂逻辑、数据分析、与用户空间交互等.
关键区别:work_queue vs irq_thread , 前者用共享线程池,后者为中断创建专用线程(开销大,但可阻塞)

Q:看门狗(Watchdog)的原理是什么?应用层怎么喂狗

A:

原理:一个独立的硬件定时器.如果程序在规定时间内没有喂狗(重置定时器),它会强制复位整个系统,防止程序跑飞或死锁.
内核驱动:内核的看门狗驱动会创建一个设备文件,通常是 /dev/watchdog.
应用层喂狗:open(“/dev/watchdog”, O_WRONLY).在一个循环或定时器中,周期性地向打开的文件描述符写入任意字符,即完成一次喂狗

Q:驱动如何给应用层封装功能和接口?

A:

标准模型:实现字符设备驱动.
核心结构体:定义一个 struct file_operations,并填充其中的函数指针.
关键函数:.open / .release:打开/关闭设备;.read / .write:数据传输,注意用 copy_to/from_user();.unlocked_ioctl:用于实现自定义控制命令(如手动复位、设置模式等).
最终效果:在 /dev/ 目录下创建设备节点,应用层像操作普通文件一样操作硬件.

Q:Linux 内核是怎么分配内存的?

A:

物理内存管理
- 伙伴系统 (Buddy System): 为内核服务,为内核进行内存分配
  - 原理: 将所有空闲的物理页框组织成11(MAX_ORDER)个链表,第i个链表中的内存块大小是2^i,i从0开始
  - 分配: 当请求N个页框时,去块大小刚好覆盖需求的链表找
    - 如果找到,则分配
    - 如果没找到,则去更大的链表找一个,将其分裂成两个同等大小的块,一个用于分配,另一个放入对应大小的链表
  - 释放: 释放内存时,会检查相邻的、地址对齐的同等大小块是否也空闲
    - 如果是,则两者合并成一个更大的块,并放入上一级链表中,这个过程会递归进行
- Slab 分配器:
  - 用于高效分配小内存减少内存碎片,机制等同于内存池
内核常用内存申请接口
- kmalloc(): 分配物理上连续的内核内存,大小通常较小
- vmalloc(): 分配虚拟上连续但物理上不一定连续的内存
- alloc_pages(): 直接从伙伴系统分配指定数量(2的幂次方)的物理页

Q: 聊聊你对指针的理解?

A:

指针存储了另一个变量的内存地址,提供了对内存的直接访问能力
- 指针的类型决定了它指向的内存区域的大小和如何解释
通用应用高效传参:
- 作为函数参数,传递地址而非对象副本,用于修改外部变量或避免大对象拷贝
- 动态内存分配:malloc/free 和 new/delete 的返回值都是指向堆区内存的指针
- 数据结构实现:是实现链表、树、图等数据结构的基础,节点之间通过指针连接.
访问硬件寄存器:
- 将已知的硬件物理地址强制转换为指针,直接读写寄存器以控制硬件.
- 中断向量表:在裸机中,中断向量表本质上是一个函数指针数组

Q: 了解二级指针吗?

A:

二级指针是一个变量,它存储的是一个一级指针的地址
核心应用场景
- 在函数内部修改外部指针变量
  - 当需要在函数内部分配内存,并让一个外部的指针指向这块新内存时使用
  - 原理:
    - 只传递一级指针是值传递,修改的是指针的副本
    - 必须传递指针的地址,通过解引用*p来修改外部的指针

Q:long指针多大?和 int 指针比呢?指针的大小由什么决定?

A:

指针变量的大小,由当前系统的体系结构(地址总线位数)决定
指针自身的大小与它指向的数据类型无关
指针类型告诉编译器两件重要事情:
- 解引用时的访问范围
- 指针运算的步长

Q: 怎么用 sizeof 判断结构体大小?char、short、int 不同组合的结构体多大?最小能压缩到多少?怎么实现?

A:

默认对齐规则:
- 成员自身对齐: 结构体中每个成员的起始地址,必须是其自身类型大小的整数倍.
- 结构体整体对齐: 结构体的总大小,必须是其所有成员中最大对齐值的整数倍.
压缩 (不对齐/Packed)最小大小: 结构体的最小大小是其所有成员大小之和
- 通过编译器指令设置1字节对齐

Q:进程和线程是啥关系?

A:

定义与核心区别
- 进程 (Process): 是操作系统进行资源分配和管理的基本单位.它是一个独立的程序执行实例,拥有自己完整的、私有的虚拟地址空间、文件描述符、内存等资源.
- 线程 (Thread): 是操作系统进行CPU调度的基本单位,也被称为轻量级进程.本身不拥有系统资源,而是依赖于其所属的进程
资源共享与隔离(关系的核心)
- 进程间资源是相互隔离的
  - 一个进程崩溃不会影响其他进程,安全性高
  - 进程创建和切换的开销大(需要切换页表、内核栈等)
  - 数据共享复杂,需要通过专门的进程间通信(IPC)机制.
- 线程共享其所属进程的绝大部分资源
  - 共享资源:堆空间,全局变量静态变量,代码段,文件描述符
  - 私有资源: 每个线程拥有自己独立的栈,用于存储局部变量和函数调用信息
  - 创建和切换开销小,数据共享非常方便,通信效率高
  - 线程的崩溃可能导致整个进程崩溃
进程是资源所有者,线程是执行者

Q: 聊聊 TCP/IP 协议?网络怎么分层的?TCP 和 IP 分别在哪一层?

A:

网络分层模型网络协议通常按功能分层,常用的是五层教学模型
- 应用层
- 传输层
- 网络层:网络寻址
- 数据链路层
- 物理层
IP协议 (位于网络层), 负责主机的IP地址寻址和数据包的路由
- 特点:无连接:,不可靠
TCP协议 (位于传输层),在IP协议之上,提供面向连接的、可靠的、基于字节流的传输服务
- 可靠性保障机制:
  - 连接管理: 三次握手和四次挥手
  - 确认与重传: 基于序列号(SEQ)和确认号(ACK)的超时重传机制
  - 流量控制: 基于接收方窗口大小的滑动窗口协议
  - 拥塞控制: 慢启动(连接初期逐步指数扩大拥塞窗口)、拥塞避免(扩大窗口至阈值变线性增长)等算法,感知并应对网络拥塞,根据丢包率延迟判断网络情况
- 字节流特性:TCP是面向字节流的,没有消息边界.这可能导致粘包/拆包问题,需要应用层协议自行解决

Q: 用二级指针申请一块内存,然后赋值并展示

A:

函数入参是二级指针
- 能存放字符串的只有char*,因此分配内存时需要mallocchar*类型
- 字符串拷贝使用strcpy
- 二级指针解引用一次是一级指针的地址,将分配的char *赋值给解引用一次的二级指针

代码实现:

void allocate_and_init(char **str, int size) { // 第1步正确:函数签名对了
    
    // 第2步:分配一块给字符串用的内存,用一个一级指针接收
    char *new_memory = (char *)malloc(size);
    if (new_memory == NULL) { return; } // 别忘了检查

    // 第3步:把字符串内容拷贝到新内存里
    strcpy(new_memory, "Hello, World!");

    // 第4步:通过解引用二级指针,修改外部的一级指针,让它指向新内存
    *str = new_memory;
}

Q:20 级台阶,一次能走 1 级或 2 级,有多少种走法?

A:

递归解法

#include <stdio.h>

int climbStairs(int n) {
    // 递归边界 (Base Case)
    if (n == 1) {
        return 1; // 1级台阶只有1种走法
    }
    if (n == 2) {
        return 2; // 2级台阶有2种走法 (1+1, 2)
    }

    // 递归关系:走到n的走法 = 走到n-1的走法 + 走到n-2的走法
    return climbStairs(n - 1) + climbStairs(n - 2);
}

int main() {
    int n = 20;
    printf("Number of ways to climb %d stairs is: %d\n", n, climbStairs(n));
    return 0;
}

动态规划解法 (面试官更期待的)
- 既然递归有重复计算,我们可以用一个数组把计算过的结果存起来,避免重复计算.这就是动态规划的思想.

Q: 描述一下嵌入式Linux的完整启动过程,并说明Bootloader的作用以及它与内核的通信方式.

A:

核心要点一:完整的启动流程
- On-Chip ROM (BootROM): CPU上电后执行的第一段固化代码.它会根据BOOT引脚的设置,从指定的启动设备(如QSPI Flash, SD卡)加载并执行第一阶段引导加载程序(FSBL).
- FSBL (First Stage Bootloader): 主要负责初始化最关键的硬件,特别是DDR内存控制器.然后它会从启动介质中加载后续的组件(如PMUFW, ATF, U-Boot)到DDR中.
- ATF & PMUFW (可选但常见): 在MPSoC中,会先加载ARM Trusted Firmware (ATF) 来建立安全环境,以及加载平台管理单元固件(PMUFW).
- U-Boot (Second Stage Bootloader): 这是功能完备的Bootloader.它会进行更全面的硬件初始化(如网口、PCIe),提供命令行交互,并最终负责加载Linux内核.
- Linux Kernel: U-Boot将内核镜像(Image)和设备树(DTB)加载到内存的指定位置,然后跳转到内核的入口点开始执行.内核会进行自解压,然后利用设备树信息初始化所有驱动,最后挂载根文件系统,并启动第一个用户进程init.
- Init Process: init进程是所有用户进程的父进程,它会根据配置文件(如inittab或systemd配置)启动其他系统服务,最终出现登录Shell.
核心要点二:Bootloader的核心作用 (为什么不能没有它)
- 硬件初始化: 它是板级硬件(Board-Specific)和通用内核(General Kernel)之间的桥梁.内核不知道具体的DDR型号、时钟频率,这些必须由Bootloader配置好,为内核创造一个可执行的基本环境.
- 加载内核镜像: 内核自身无法从Flash中把自己加载到RAM中运行,这个搬运工的角色必须由Bootloader来承担.
- 传递启动参数: Bootloader是向内核传递信息的第一个入口.它告诉内核根文件系统在哪、控制台用哪个串口等关键信息.
- 提供调试和恢复功能: 提供命令行,允许开发者在内核启动前进行调试、系统更新或进入恢复模式.
核心要点三:Bootloader与内核的通信机制核心机制:
- 设备树 (Device Tree Blob - DTB)
  - U-Boot在启动内核前,会将内核镜像和DTB文件加载到内存中的不同地址.
  - DTB中不仅包含了板上几乎所有的硬件信息描述(如CPU核数、内存地址和大小、外设寄存器地址、中断号等),U-Boot还会动态地修改DTB,将启动参数(bootargs)写入chosen节点下.
- 传递方式:
  - U-Boot在跳转到内核入口点时,会遵循ARM的启动协议,将DTB在内存中的物理地址存放在一个约定的寄存器中(如ARM32的r2,ARM64的x0).
  - 内核启动后,会从这个约定的寄存器中获取地址,找到DTB,解析它来初始化对应的硬件驱动,并从chosen节点读取bootargs来执行后续的启动流程.

Q: 互斥锁(Mutex)和自旋锁(Spinlock)的根本区别是什么?在嵌入式Linux驱动开发中,您会如何选择使用它们?请至少举一个必须使用自旋锁,而不能使用互斥锁的具体场景.

A:

核心要点一:根本区别在于等待方式
- 互斥锁 (Mutex): 获取锁失败时,当前执行单元会进入睡眠状态,让出CPU给其他任务.这是一种不占用CPU的等待.
  - 优点:等待期间不消耗CPU,适用于锁保护的代码执行时间可能较长的场景.
  - 缺点:涉及进程/线程的上下文切换,开销较大.
- 自旋锁 (Spinlock): 获取锁失败时,当前执行单元会进入一个忙等待循环(原地自旋),持续占用CPU直到锁被释放.这是一种占用CPU的等待.
  - 优点:没有上下文切换的开销,适用于锁保护的代码执行时间非常短的场景.
  - 缺点:如果锁占用时间长,会严重浪费CPU资源.
核心要点二:选择原则与适用场景
- 预期的锁持有时间:
  - 如果锁的持有时间很短(通常是微秒级别,几条汇编指令就能完成),应优先使用自旋锁,因为上下文切换的开销可能比锁的持有时间还要长.
  - 如果锁的持有时间可能很长,或者在锁保护的区域内可能发生睡眠(如调用copy_from_user、kmalloc等可能引起阻塞的函数),则必须使用互斥锁.
- 执行的上下文: 这是最关键的区别.
  - 互斥锁只能在进程上下文中使用,因为它需要睡眠.
  - 自旋锁可以在进程上下文和中断上下文中使用.
核心要点三:必须使用自旋锁的场景——中断处理程序
- 场景描述: 当一个设备驱动的中断处理程序需要访问一个与驱动其他部分(如read/write函数)共享的全局数据结构时,必须使用自旋锁来保护这个数据结构.
- 原因分析:
  - 中断处理程序运行在中断上下文中,这是一个特殊的、不能被调度的环境.
  - 如果在中断上下文中使用互斥锁,并且该锁恰好被进程上下文的代码持有,中断处理程序会尝试睡眠以等待锁.
  - 在中断上下文中睡眠是绝对不允许的,因为中断处理程序没有一个可以被内核调度器重新调度回来的进程实体.这将导致系统死锁 (Deadlock) 和崩溃.
  - 因此,自旋锁是中断上下文中唯一可用的锁机制.

Q: 当Linux内核出现问题时,比如发生了Kernel Panic或者Oops,你通常会如何去排查?请描述你的调试思路和具体使用过的工具.

A:

前置知识
- Oops: 它发生在内核态代码访问了无效的内存地址(比如空指针解引用)或执行了非法指令时
  - 产生Oops后,内核会杀死当前进程(因为是这个进程的系统调用触发了内核错误),但内核本身会尝试继续运行
  - 系统不一定会立即宕机,但会处于一个不稳定状态,很可能在不久后因为数据结构损坏而最终Panic.Oops信息是调试驱动问题的最重要线索.
- Kernel Panic: 这是内核遇到的致命错误,无法恢复.一旦发生Panic,内核会停止所有任务,打印尽可能多的调试信息,然后系统彻底宕机.Panic的原因有很多,比如找不到根文件系统、关键的内核数据结构损坏、或者由一个未处理的Oops引发
第一步:获取日志 (保存现场)
- 核心工具: 串口 + 日志记录软件 (Minicom/Putty).
- 关键信息: 重点关注日志中的三样东西:
  1. 错误摘要: 比如 NULL pointer dereference (空指针) 或 sleeping function called from invalid context (上下文错误).
  2. PC/IP 值: 指令指针,也就是出错的内存地址.
  3. Call Trace: 函数调用栈,能看出代码是怎么跑到出错点的.
第二步:定位源码 (翻译地址)
- 核心工具: addr2line
- 操作公式: addr2line -e vmlinux <PC值>.
  - vmlinux 是带调试信息的内核镜像.
  - <PC值> 就是上一步日志里的那个内存地址.
- 达成效果: 这个命令能把看不懂的内存地址,直接翻译成哪个文件的第几行.
第三步:分析修复 (对症下药)
- 定位后: 结合第二步找到的源码位置和第一步的函数调用栈,审查代码逻辑.

Q: 阻塞I/O和非阻塞I/O的根本区别、优劣势是什么?为什么高性能服务器多采用非阻塞模型?

A:

前置知识
- Linux中几乎所有的I/O操作,在内核层面最终都会归结为对文件描述符的操作
- 当我们调用一个I/O函数(如read, recv)时,分为两个阶段:
  - 等待数据阶段: 内核等待硬件准备好数据.比如,网卡接收到数据包,并把它复制到内核缓冲区.
  - 拷贝数据阶段: 内核把准备好的数据,从内核缓冲区拷贝到我们应用进程的内存空间.
- 阻塞I/O和非阻塞I/O的根本区别,就体现在等待数据阶段应用进程的状态
核心要点一:根本区别在于等不等
- 阻塞I/O (Blocking I/O):
  - 行为: 当应用调用read等函数,如果内核的数据还没准备好,应用进程会被挂起(进入睡眠状态),完全放弃CPU,直到数据准备好并被拷贝到用户空间后,才会被唤醒.
  - 特点: 一个线程在I/O操作完成前,什么都干不了.调用即阻塞.
- 非阻塞I/O (Non-blocking I/O):
  - 行为: 当应用调用read等函数,如果内核数据没准备好,该函数会立即返回一个错误码 (例如EAGAIN或EWOULDBLOCK),而不会让应用进程睡眠.
  - 特点: 调用立即返回,不阻塞.应用进程需要通过一个循环来不断尝试读取,直到成功为止.
核心要点二:优劣势对比
- 阻塞I/O:
  - 优点: 编程模型简单,代码逻辑是线性的,易于理解.
  - 缺点: 性能极差,并发能力低下.一个线程只能处理一个I/O连接.如果要同时处理大量连接,就需要创建大量线程,导致巨大的内存开销和CPU上下文切换开销,最终拖垮服务器.
- 非阻塞I/O:
  - 优点: 不会被单个I/O操作卡死,可以在等待数据的间隙去做别的事情.
  - 缺点: 编程模型复杂.单纯的非阻塞I/O会导致应用进程在循环中不断查询,形成忙等待,浪费CPU.
核心要点三:为何选择非阻塞 (引出I/O多路复用)
- 问题演进: 单纯的非阻塞I/O模型因为会忙等,所以很少直接使用.它的价值在于和I/O多路复用技术 (如select, poll, epoll) 结合.
- I/O多路复用: 它的作用是批量查询.应用进程可以一次性把自己关心的所有文件描述符(FD)都交给内核,然后自己进入阻塞睡眠状态,由内核来等待描述符数据到来,唤醒用户程序

Q: 为什么基类的析构函数通常需要被声明为虚函数?如果不是虚函数,会发生什么问题?

A:

核心要点一:根本原因–为了实现多态下的正确析构
- 一句话总结:将基类析构函数声明为virtual,是为了确保当通过基类指针或引用删除一个派生类对象时,能够正确地调用派生类的析构函数,从而避免资源泄漏.
编译器调用析构函数时,如果析构是虚的,就知道这个是基类,应该去调用子类的析构
然后如果发现这个对象的析构函数是实的,就不考虑子类的事情,然后直接调用

Q: 内核与用户态通信:除了 ioctl,还了解哪些机制?实际用过哪些?

A:

内核与用户态的通信机制可以根据其主要用途分为两大类:数据平面和控制平面.

数据平面 (主要用于高效传输大块数据)
- 内存映射 (mmap):
  - 核心优势是实现零拷贝(Zero-copy),用户空间和内核空间共享同一块物理内存,避免了不必要的数据复制,是最高效的方式
  - UIO (Userspace I/O) 本质上也是对mmap机制的一种简化封装,方便用户态直接访问设备寄存器和内存.
控制平面 (主要用于发送命令、获取状态、传递短消息)
- ioctl (Input/Output Control):
  - 最传统、最直接的控制通道,通过一个命令号来区分不同的操作.
  - 优点是直接,缺点是命令号需要内核和应用层同步,扩展不便,且是同步阻塞调用.
- procfs / sysfs 虚拟文件系统:
  - 将设备的状态和参数暴露为文件系统中的文件,用户态通过简单的read/write操作即可查询或配置驱动.
  - 例如,在嵌入式项目中,可以通过echo 1 > /sys/class/leds/user-led/brightness来点亮一个LED灯.这种方式非常直观,便于脚本自动化.
- Netlink Socket:
  - 一种专门用于内核与用户态进程通信的socket,功能强大.
  - 支持全双工、异步通信,消息传递是结构化的,非常适合内核主动向用户态发送事件通知.例如,网络设备状态变化(网线插拔)就是通过Netlink通知上层的

Q: 中断底半部的 tasklet 和 workqueue 有什么区别?如果让你在一个驱动中处理一个可能会休眠的操作,你会选择哪个?为什么?

A:

核心区别 (上下文与休眠能力)
- Tasklet (小任务):
  - 上下文: 在软中断上下文中执行,这是一个特殊的、不能被调度的上下文.
  - 休眠: 绝对不允许休眠.在软中断上下文中调用任何可能导致睡眠的函数(如 kmalloc、mutex_lock、copy_from_user 等)都会导致系统崩溃(Kernel Panic).
  - 并发: 同一个 tasklet 不会在多个 CPU 上同时执行,但不同 tasklet 可以在不同 CPU 上并发执行.
  - 适用场景: 处理那些执行快、不休眠、与硬件强相关的延迟任务.
- Workqueue (工作队列):
  - 上下文: 在内核线程上下文中执行,也称为进程上下文.
  - 休眠: 允许休眠.因为它本质上就是一个内核线程,所以拥有进程上下文的所有能力,可以被内核正常调度,也可以安全地调用会导致阻塞或休眠的函数.
  - 并发: 由内核线程池管理,并发能力更强,调度更灵活.
  - 适用场景: 处理那些可能耗时较长或需要休眠的延迟任务,比如进行文件I/O、复杂的计算、或者需要获取锁等

Q: C 语言内存管理中,`malloc` 和 `mmap` 有什么区别?什么时候会考虑使用 `mmap`?

A:

层面与来源不同
- malloc: 是C标准库函数.它是一个用户态的内存分配器,负责管理进程的堆(Heap)内存.为了提高效率,它底层会通过 brk 或 mmap 系统调用向内核申请大块内存,然后切分成小块分配给程序.
- mmap: 是一个系统调用.它直接请求内核,将一个文件或设备映射到进程的虚拟地址空间.
核心用途不同
- malloc: 主要用于通用的、动态的内存分配.当程序需要一块大小不定的内存来存储数据时,malloc 是最常规和首选的方式.
- mmap: 主要用于以下特定场景:
  - 高性能文件I/O: 将大文件映射到内存,可以像操作数组一样直接读写,避免了 read/write 带来的内核态和用户态之间的数据拷贝开销,实现零拷贝.
  - 进程间共享内存: 多个进程映射同一个文件到各自的地址空间,可以实现高效的数据共享,是重要的IPC(进程间通信)手段.
  - 映射设备内存: 在驱动编程中,将硬件设备的物理地址(如寄存器、显存)映射到内存,使得程序可以直接通过内存地址来操作硬件.这在我的Zynq项目中就曾使用过.

Q: 进程间通信中,共享内存 + 信号量和 socket 的方案,各自有什么优缺点?

A:

适用范围
- 共享内存: 仅限同一主机.它是把同一块物理内存映射到不同进程的虚拟地址空间.
- Socket: 既可用于同一主机,也可用于跨网络的主机间通信.这是它最大的优势.
性能与数据拷贝
- 共享内存: 最快.数据一旦写入,其他进程立刻可见,真正实现了零拷贝,非常适合大数据量、低延迟的场景.
- Socket: 较慢.传统read/write模式涉及至少两次数据拷贝(内核缓冲区 <-> 用户缓冲区).虽然可以通过 sendfile 等高级API在特定场景(如文件到网络)实现零拷贝,但通用性不如共享内存.
同步机制
- 共享内存: 无内置同步机制.它本身只是一块裸内存,必须借助外部工具(如信号量、互斥锁)来保证数据的一致性和避免竞态条件,这增加了编程的复杂性.
- Socket: 自带基本同步.read/write操作是原子的,并且默认的阻塞式I/O提供了一种隐式的同步,简化了编程模型.
使用复杂度
- 共享内存: 高.需要手动处理复杂的同步问题,容易出错(如死锁、数据污染).
- Socket: 相对较低.API(bind, listen, accept, connect)是标准化的,客户端/服务器模型非常成熟和通用.

Q: 你用过哪些内核调试手段(printk、ftrace、gdb、perf)?分别适用于什么场景?

A:

printk (打印内核日志)
- 是什么: 内核版的 printf,用于向内核日志缓冲区输出信息.可以通过 dmesg 命令查看.
ftrace (函数跟踪器)
- 是什么: 内核内置的、功能强大的跟踪框架,可以用来监控内核函数的行为.
- 适用场景:
  - 性能分析/延迟问题: function_graph 跟踪器可以清晰地展示函数调用链及每个函数的执行时间,非常适合定位导致高延迟的函数.
  - 逻辑流程分析: 跟踪特定函数的调用者(caller)和被调用者(callee),理清复杂的代码执行路径.
  - 事件跟踪: 跟踪内核中的特定事件,比如中断、调度、系统调用等,理解系统内部的交互.
GDB (配合 kgdb/kdb)
- 是什么: 熟悉的用户态GDB调试器,通过 kgdb 或 kdb 桩(stub)可以用来调试一个正在运行的内核.
- 适用场景:
  - 内核崩溃/死锁现场分析: 当系统完全卡死(Panic 或 Deadlock)时,可以通过串口或网络连接 kgdb,进行现场勘查.可以查看所有线程的堆栈、检查变量值、内存状态等.
  - 复杂逻辑的单步调试: 对于特别复杂的算法或逻辑,可以设置断点,进行单步跟踪,观察每一步的状态变化.这是一种侵入性最强的调试方式.
perf (性能分析工具)
- 是什么: 一个功能强大的性能分析工具集,基于处理器的性能监控单元(PMU).
- 适用场景:
  - CPU 性能瓶颈分析:
    - perf top 可以实时显示当前系统中CPU消耗最高的函数
    - perf record 和 perf report 可以生成详细的性能剖析报告,告诉你CPU时间主要花在了哪些函数上
  - Off-CPU 分析: 分析进程/线程因为何种原因(如等待I/O、锁)而睡眠,没有在CPU上运行.
  - 硬件事件分析: 监控CPU的缓存命中率(cache misses)、分支预测失败(branch misses)等底层硬件事件

Q: C++虚函数表是怎样的?虚继承和普通继承在内存布局上的区别?

A:

虚函数表 (vtable)
- 核心机制: 当一个类含有虚函数时,编译器会为该类创建一个静态的、唯一的虚函数表(vtable).vtable本质上是一个函数指针数组,按顺序存放着类中所有虚函数的地址.
- 对象模型: 每个包含虚函数的类的实例,其内存布局的起始位置会包含一个虚函数表指针 (vptr),指向该类的vtable.
- 多态实现:
  - 子类的虚函数表是父类虚函数表的一个完整副本
  - 虚函数表是类级别的,被该类所有对象共享,类所有实例的vptr指向同一个vtable
  - 子函数重写:会覆盖子函数对应的虚函数表的对应条目,更新为重写后函数的地址
  - 父类型的子类实例调用虚函数,编译器会根据父类型的信息获取对应虚函数的偏移量,调用时则是通过子虚函数表+偏移量正确的找到对应的重写后的函数
内存布局区别
- 普通继承: 子类会完整地包含父类的所有成员(包括vptr,如果有的话),然后再加上自己的成员.如果有多个父类,就依次平铺排列.
- 虚继承(在父类名前加上 virtual 关键字开启虚继承)
  - 目的: 解决菱形继承中,最顶层基类成员在最终派生类中出现多次(冗余、二义性)的问题.
  - 核心区别: 子类不再直接包含基类的成员,而是包含一个虚基类表指针 (vbptr).这个指针指向一个虚基类表,表中记录了虚基类成员相对于当前对象地址的偏移量.
  - 效果: 无论虚基类被继承多少次,在最终的派生类对象中,永远只存在一份唯一的虚基类成员实例.

Q:epoll边缘触发和水平触发有什么区别?ET模式下如何避免丢事件?

A:

epoll在内核维护一个fd列表,当fd活跃会通知epoll实例,epoll把活跃的列表返回给用户程序

核心区别
- 水平触发-默认模式:
  - 条件: 只要文件描述符(fd)上的缓冲区还有数据可读(或还有空间可写),epoll_wait 每次返回都会通知你.
  - 类比: 只要电压保持在高电平,告警就一直响.
  - 优点: 编程简单,不易出错.即使这次没处理完,下次 epoll_wait 还会提醒你.
- 边缘触发-高速模式:
  - 条件: 仅当 fd 上的状态发生变化时(例如,数据从无到有,或缓冲区从满到不满),epoll_wait 才会通知你,并且只通知一次.
  - 类比: 只有在电压从低电平跳变到高电平的那一瞬间,告警才响一声.
  - 优点: 效率更高,因为它避免了 epoll_wait 的重复唤醒.
ET 模式避免事件丢失
- 核心原则: 收到一次通知后,必须循环处理该 fd 上的所有数据,直到返回 EAGAIN 或 EWOULDBLOCK 错误为止.
- 具体做法:
  - 原因: 如果不这样做,只 read 一次,而缓冲区里其实还有数据,由于是 ET 模式,epoll_wait 将不会再通知你,导致剩余的数据被丢失.

Q: 实时信号和普通信号的区别?如何保证信号不丢失?

A:

普通信号
- 范围: 信号值为 1-31,如 SIGINT, SIGKILL.
- 不可靠性:
  - 不支持排队: 如果一个信号在被处理前被多次发送,内核只会将它合并为一次,最终只递交一次.
  - 无附加信息: 信号本身不携带额外数据.
实时信号 (Real-time Signals):
- 范围: 信号值为 34-64 (Linux中).
- 可靠性:
  - 支持排队: 发送多少次,就会在接收进程的队列中保留多少次,不合并.
  - 可携带数据: 可以通过 sigqueue 发送信号,并附带一个整数或指针值.
如何保证信号不丢失:
- 核心: 在可能产生信号丢失的临界区代码执行前,阻塞该信号；在临界区结束后,再解除阻塞

Q: 什么是系统调用?

A:

核心定义与目的
- 定义: 系统调用是操作系统内核提供给用户态应用程序的一个接口,用于请求内核提供服务.
- 目的: 将系统资源的管理置于内核态,防止用户程序直接操作硬件或访问任意内存,从而避免系统崩溃.
执行流程
- 封装: 应用程序通常不直接执行系统调用,而是调用C库(如glibc)提供的封装函数(例如 open()).
- 触发: C库函数设置好系统调用所需的参数(包括唯一的“系统调用号”),然后执行一条特殊的CPU指令(如syscall或int 0x80)来触发一个陷阱 (Trap).
- 切换: CPU检测到陷阱后,会立即从用户态切换到内核态,并跳转到内核中预先定义好的入口点——系统调用处理程序.
- 执行: 内核根据传递的“系统调用号”,在系统调用表 (System Call Table) 中找到对应的内核函数并执行.
- 返回: 内核函数执行完毕后,将结果返回给用户程序,CPU再从内核态切换回用户态,应用程序继续执行.

Q: map和unordered_map区别

A:

核心区别
- map: 基于红黑树 (Red-Black Tree) 实现.红黑树是一种自平衡的二叉查找树.
- unordered_map: 基于哈希表 (Hash Table) 实现.
主要差异点对比
- 有序性:
  - map: 元素会根据键 (key) 自动排序.遍历时得到的是一个有序序列.
  - unordered_map: 元素是无序的,其存储顺序由哈希函数和哈希冲突解决方法决定.
- 效率 (时间复杂度):
  - map: 插入、删除、查找操作的时间复杂度都是 O(log N),其中N是元素的数量.性能非常稳定.
  - unordered_map: 在理想情况下(哈希函数良好,冲突少),插入、删除、查找操作的平均时间复杂度是 O(1).但在最坏情况下(所有元素哈希到同一个桶),会退化到 O(N).
- 内存占用:
  - unordered_map 通常会消耗更多的内存,因为它需要维护哈希表结构,为了减少冲突,装载因子通常小于1,会有空间冗余.
- 对键 (Key) 的要求:
  - map: 键必须支持 < 比较运算符.
  - unordered_map: 键必须提供对应的哈希函数 std::hash<Key> 和 等于运算符 ==

Q:说一下PCIE从握手到驱动加载的过程

A:

阶段一:物理层链路建立 (握手)
- 上电: PCIe设备上电,物理层进入链路训练和状态状态机 (LTSSM).
- 训练: Root Complex (RC, 如CPU侧的控制器) 和 Endpoint (EP, 如M.2 SSD) 的物理层通过交换一系列预定义的训练序列来协商链路参数,如链路宽度 (x1, x4, x8, x16) 和链路速率 (Gen1-5).
- 进入L0状态: 双方协商一致,链路成功建立,进入 L0 状态,表明链路已激活,可以开始传输TLP事务层数据包.这是所有后续操作的基础.
阶段二:固件/硬件层总线枚举
- 扫描: BIOS或U-Boot等固件代码,从Bus 0开始,通过深度优先搜索 (DFS) 的方式扫描所有PCIe总线.
- 配置读写: 固件向总线上的每个设备功能 (由 BDF: Bus, Device, Function号唯一标识) 发送配置读请求,读取其配置空间 (Configuration Space) 头部的 Vendor ID 和 Device ID.
- 资源分配: 如果设备存在 (Vendor ID有效),固件会为其分配系统资源,主要是:
  - 分配总线号: 如果设备是PCIe桥,会为桥下方的总线分配新的总线号.
  - 分配BAR空间: 读取设备的基地址寄存器 (BARs) 的大小需求,然后在系统的物理地址空间中为其分配一段内存或I/O空间,并将分配的基地址写回设备的BAR寄存器.
阶段三:内核初始化与驱动加载
- Host驱动加载: Linux内核启动,设备树(Device Tree)被解析.其中描述PCIe Host Controller节点的 compatible 属性会匹配到对应的 PCIe主机控制器驱动并加载它.
- 内核重新扫描: 主机控制器驱动初始化后,Linux内核的PCIe子系统会重新执行一次完整的总线扫描 (类似阶段二),忽略固件的扫描结果(但会保留其资源分配结果).lspci 命令看到的就是这次内核扫描的结果.
- 设备注册: 内核每发现一个设备,就读取其Vendor ID, Device ID, Class Code等信息,并为其创建一个 pci_dev 结构体,注册PCI核心
- 驱动匹配与probe:
  - 当 pci_dev 注册时,PCIe核心会去遍历所有已注册的 pci_driver.
  - 每个PCIe设备驱动(如NVMe驱动)都会有一个 pci_device_id表,里面定义了它所支持的 {Vendor ID, Device ID} 列表.
  - 如果内核发现一个设备的ID与某个驱动的 id_table 中的条目匹配,匹配成功！
  - 内核随即调用该驱动的 probe 函数.驱动在 probe 函数中执行初始化工作,如 pci_enable_device()激活设备,pci_request_regions()声明对BAR空间的占用, pci_iomap() (将BAR对应的物理地址重新映射到内核的虚拟地址空间) 等,完成设备初始化
  - 向块设备层注册一个新的磁盘设备
  - 块设备层触发udev等用户空间服务,创建/dev设备节点

Q:DDR挂在PS还是PL下面,为什么?如何选择挂在PS还是PL呢?

A:

Q:你做过哪些驱动开发 / 你的驱动是怎么实现的

A:

Q:硬件的复位电平/延时要求不同,驱动里怎么处理

A:

Q:如何实现一个中断

A:

Q:看门狗(Watchdog)的原理是什么?应用层怎么喂狗

A:

Q:驱动如何给应用层封装功能和接口?

A:

Q:Linux 内核是怎么分配内存的?

A:

Q: 聊聊你对指针的理解?

A:

Q: 了解二级指针吗?

A:

Q:long指针多大?和 int 指针比呢?指针的大小由什么决定?

A:

Q: 怎么用 sizeof 判断结构体大小?char、short、int 不同组合的结构体多大?最小能压缩到多少?怎么实现?

A:

Q:进程和线程是啥关系?

A:

Q: 聊聊 TCP/IP 协议?网络怎么分层的?TCP 和 IP 分别在哪一层?

A:

Q: 用二级指针申请一块内存,然后赋值并展示

A:

Q:20 级台阶,一次能走 1 级或 2 级,有多少种走法?

A:

Q: 描述一下嵌入式Linux的完整启动过程,并说明Bootloader的作用以及它与内核的通信方式.

A:

Q: 互斥锁(Mutex)和自旋锁(Spinlock)的根本区别是什么?在嵌入式Linux驱动开发中,您会如何选择使用它们?请至少举一个必须使用自旋锁,而不能使用互斥锁的具体场景.

A:

Q: 当Linux内核出现问题时,比如发生了Kernel Panic或者Oops,你通常会如何去排查?请描述你的调试思路和具体使用过的工具.

A:

Q: 阻塞I/O和非阻塞I/O的根本区别、优劣势是什么?为什么高性能服务器多采用非阻塞模型?

A:

Q: 为什么基类的析构函数通常需要被声明为虚函数?如果不是虚函数,会发生什么问题?

A:

Q: 内核与用户态通信:除了 ioctl,还了解哪些机制?实际用过哪些?

A:

Q: 中断底半部的 tasklet 和 workqueue 有什么区别?如果让你在一个驱动中处理一个可能会休眠的操作,你会选择哪个?为什么?

A:

Q: C 语言内存管理中,malloc 和 mmap 有什么区别?什么时候会考虑使用 mmap?

A:

Q: 进程间通信中,共享内存 + 信号量和 socket 的方案,各自有什么优缺点?

A:

Q: 你用过哪些内核调试手段(printk、ftrace、gdb、perf)?分别适用于什么场景?

A:

Q: C++虚函数表是怎样的?虚继承和普通继承在内存布局上的区别?

A:

Q:epoll边缘触发和水平触发有什么区别?ET模式下如何避免丢事件?

A:

Q: 实时信号和普通信号的区别?如何保证信号不丢失?

A:

Q: 什么是系统调用?

A:

Q: map和unordered_map区别

A:

Q:说一下PCIE从握手到驱动加载的过程

A:

Q: C 语言内存管理中,`malloc` 和 `mmap` 有什么区别?什么时候会考虑使用 `mmap`?