为何Linux GPIO v2 API强制要求GPIO引脚独占所有权？

• 杜绝资源竞态：旧sysfs API无独占机制，多个进程同时操作同一GPIO时，会出现状态冲突（比如一个设高电平、一个设低电平），排查难度极大。强制独占把控制权明确到单一持有者，从根源避免这类问题。
• 简化内核实现：sysfs的多进程访问和边带配置需要内核维护复杂的同步逻辑，GPIO v2通过ioctl+独占申请的模式，让内核无需处理共享状态，大幅降低代码复杂度和bug概率。
• 适配硬件高级特性：现代GPIO控制器支持中断、触发模式配置、多路复用等功能，这些特性的配置和使用必须保证独占，否则不同进程的配置会互相覆盖，导致硬件行为异常。

针对你遇到的两个典型场景，给出具体解决办法：

场景1：批量记录GPIO状态用于调试 #

无需编写内核驱动，利用现有工具和接口即可实现：

• 使用libgpiod套件自带的gpioinfo工具，它能直接读取所有GPIO的状态，无需申请独占权限——工具通过内核的只读查询接口获取数据，不会占用引脚控制权。你可以通过定时任务（比如cron）调用该工具，将输出重定向到日志文件。
• 若需要自定义日志格式，基于libgpiod编写轻量工具，调用gpiod_chip_get_line_info()系列函数，这些接口专门用于查询引脚状态，无需申请独占线路。

场景2：关机引脚同时支持gpio-poweroff和手动控制 #

核心是保证两者的时序不冲突：

• 让应用临时申请引脚：仅在需要计时控制时申请引脚，操作完成后立即释放。gpio-poweroff驱动仅在关机流程的最后阶段申请引脚，只要你的应用在收到关机信号（如SIGTERM）时及时释放，驱动就能正常获取控制权。
• 配置引脚优先级：通过设备树或内核参数调整gpio-poweroff的行为，让驱动仅在关机阶段接管引脚，平时引脚处于空闲状态，应用可按需申请使用。

通用规避思路：

• 只读场景优先用查询接口：libgpiod提供了无需独占的状态查询函数，避免占用引脚资源。
• 共享场景采用“按需申请、用完释放”模式：避免长期独占引脚，给其他进程/驱动留出使用空间。
• 多进程共享需求用用户态守护进程：编写一个守护进程独占引脚，通过Unix域套接字等方式提供统一控制接口，由它处理同步和权限，成本远低于编写内核驱动。

• GPIO v2支持只读共享：内核提供GPIO_V2_LINE_FLAG_SHARED标志，允许多个进程以只读方式共享引脚（仅能读取状态，无法修改配置或输出电平），正好适配调试记录的场景。
• gpio-poweroff的工作时机：该驱动仅在系统关机的最后阶段激活，只要应用在关机前释放引脚，两者不会产生冲突。
• libgpiod的封装价值：无需直接操作ioctl，libgpiod提供了简洁的API封装，覆盖大部分GPIO操作需求，包括只读查询、临时申请等。

内容的提问来源于stack exchange，提问作者Tim Vrakas