谈谈Linux内核驱动的编码风格

简介:

最近在向Linux内核提交一些驱动程序,在提交的过程中,发现自己的代码离Linux内核的coding style要求还是差很多。当初自己对内核文档里的CodingStyle一文只是粗略的浏览,真正写代码的时候在很多细节上会照顾不周。不过, 在不遵守规则的程序员队 伍里,我并不是孤独的。如果去看drivers/staging下的代码,就会发现很多驱动程序都没有严格遵守内核的coding style,而且在很多驱动程序的TODO文件里,都会把”checkpatch.pl fixes”作为自己的目标之一(checkpatch.pl是用来检查代码是否符合coding style的脚本)。

不可否认,coding style是仁者见仁、智者见智的事情。比如Microsoft所推崇的匈牙利命名法,在Linus看来就是及其脑残(brain damaged)的做法。也许您并不赞成Linus制定的coding style,但在提交内核驱动这件事上,最好还是以大局为重。对于这么一个庞大的集市式的开发来说,随意书写代码必将带来严重的可维护性的灾难。

一些辅助工具

当代码量达到一定程度时,手动去检查和修改coding style是非常繁琐的工作,幸好,我们还有一些工具可以使用。

scripts/checkpatch.pl

这是一个检查代码是否符合内核编码规范的的脚本。顾名思义,checkpatch是用来检查patch的,默认的调用也确实如此。如果用来检查原文件,需要加上“-f”的选项。

我们来看一段无聊的代码(文件名为print_msg.c):


  
  
  1. void print_msg(int a) 
  2. switch (a) { 
  3. case 1: 
  4. printf("a == 1\n"); 
  5. break; 
  6.  
  7. case 2: 
  8. printf("a == 2\n"); 
  9. break; 
  10.  

这段代码的coding style是否有问题呢?用checkpatch.pl来检查一下:

scripts/checkpatch.pl -f print_msg.c

检查的结果是:


  
  
  1. ERROR: switch and case should be at the same indent 
  2. #3: FILE: switch.c:3: 
  3. + switch (a) { 
  4. case 1: 
  5. [...] 
  6. case 2: 
  7.  
  8. total: 1 errors, 0 warnings, 12 lines checked 
  9.  
  10. switch.c has style problems, please review. If any of these errors 
  11. are false positives report them to the maintainer, see 
  12. CHECKPATCH in MAINTAINERS.  

在Linux内核的coding style里,switch和case要求有相同的缩进。本例的代码很少,错误也只有这一个,手动修改很方便。如果类似的缩紧错误很多怎么办?

scripts/Lindent

scripts目录下的工具Lindent可以用来自动修改缩进问题。提醒一下,使用Lindent要求系统安装indent这个工具。

对于上面这个例子,执行Lindent命令:

scripts/Lindent print_msg.c

得到的新代码是:


  
  
  1. void print_msg(int a) 
  2. switch (a) { 
  3. case 1: 
  4. printf("a == 1\n"); 
  5. break; 
  6.  
  7. case 2: 
  8. printf("a == 2\n"); 
  9. break; 
  10.  

sed

sed是一个流编辑器,其强大的功能可以帮助我们处理很多重复性的工作。比如,Linux内核的coding style要求,行尾不能有空格(包括Tab),去除这些空格就可以借助sed。

我自己的习惯很差,经常在代码的行尾留下一些空格。比如一行代码过长需要换行时,总是下意识的在换行的地方敲一个空格。另外,我常用的编辑器之一的Kate,为了对齐的需要,经常在空行的前面留上几个缩进的Tab(如下图)。

手动去除这些行尾的空格是一件头大的事情,但对于sed来说不过是举手之劳。命令格式如下:


  
  
  1. sed ‘s/[ \t]*$//g’ your_code.c 

一些需要注意的Coding Style

缩进

1、除了注释、文档和Kconfig之外,使用Tab缩进,而不是空格,并且Tab的宽度为8个字符;

2、switch … case …语句中,switch和case具有相同的缩进(参考上文);

花括号

3、花括号的使用参考K&R风格。

如果是函数,左花括号另起一行:


  
  
  1. int function(int x) 
  2. body of function 
  3.  

否则,花括号紧接在语句的最后:


  
  
  1. if (x is true) { 
  2. we do y 
  3.  

如果只有一行语句,则不需要用花括号:


  
  
  1. if (condition) 
  2. action();  

但是,对于条件语句来说,如果一个分支是一行语句,另一个分支是多行,则需要保持一致,使用花括号:


  
  
  1. if (condition) { 
  2. do_this(); 
  3. do_that(); 
  4. else { 
  5. otherwise(); 
  6.  

空格

4、在关键字“if, switch, case, for, do, while”之后需要加上空格,如:

if (something)

5、在关键字“sizeof, typeof, alignof, or __attribute__”之后不要加空格,如:

sizeof(struct file)

6、在括号里的表达式两边不要加空格,比如,下面是一个反面的例子:

sizeof( struct file )

7、大多说的二元和三元运算符两边需要空格,如“= + – < > * / % | & ^ <= >= == != ? :”;

8、一元运算符后面不要空格,如“& * + – ~ ! sizeof typeof alignof __attribute__ defined”;

9、在前缀自增自减运算符之后和后缀自增自减运算符之前不需要空格(“++”和“–”);

10、结构成员运算符(“.”和“->”)的两边不需要空格;

11、行尾不需要空格;

注释

12、使用C89的“/* … */”风格而不是C99的“// …”风格;

13、对于多行注释,可以参考下例:


  
  
  1. /* 
  2. * This is the preferred style for multi-line 
  3. * comments in the Linux kernel source code. 
  4. * Please use it consistently. 
  5. * Description: A column of asterisks on the left side, 
  6. with beginning and ending almost-blank lines. 
  7. */  

Kconfig

14、“config”定义下面的语句用Tab缩进,help下面的语句再额外缩进两个空格,如:


  
  
  1. config AUDIT 
  2. bool "Auditing support" 
  3. depends on NET 
  4. help 
  5. Enable auditing infrastructure that can be used with another 
  6. kernel subsystem, such as SELinux (which requires this for 
  7. logging of avc messages output). Does not do system-call 
  8. auditing without CONFIG_AUDITSYSCALL.  

15、多行的宏定义需要用“do .. while”封装,如:


  
  
  1. #define macrofun(a, b, c) \ 
  2. do { \ 
  3. if (a == 5) \ 
  4. do_this(b, c); \ 
  5. } while (0)  

函数返回值

16、函数返回值的定义最好也要遵循一定的章法。

如果函数的名称是一种动作或者命令式的语句,应该以错误代码的形式返回(通常是0表示成功,-Exxx这种形式的负数表示错误),如:

do_something()

如果函数的名称是判断语句,则返回值应该类似与布尔值(通常1表示成功,0表示错误),如:

something_is_present()





本文作者:佚名
来源:51CTO
目录
相关文章
|
16天前
|
安全 Linux 编译器
探索Linux内核的奥秘:从零构建操作系统####
本文旨在通过深入浅出的方式,带领读者踏上一段从零开始构建简化版Linux操作系统的旅程。我们将避开复杂的技术细节,以通俗易懂的语言,逐步揭开Linux内核的神秘面纱,探讨其工作原理、核心组件及如何通过实践加深理解。这既是一次对操作系统原理的深刻洞察,也是一场激发创新思维与实践能力的冒险。 ####
|
1天前
|
Linux 数据库
Linux内核中的锁机制:保障并发操作的数据一致性####
【10月更文挑战第29天】 在多线程编程中,确保数据一致性和防止竞争条件是至关重要的。本文将深入探讨Linux操作系统中实现的几种关键锁机制,包括自旋锁、互斥锁和读写锁等。通过分析这些锁的设计原理和使用场景,帮助读者理解如何在实际应用中选择合适的锁机制以优化系统性能和稳定性。 ####
14 6
|
1天前
|
机器学习/深度学习 负载均衡 算法
深入探索Linux内核调度机制的优化策略###
本文旨在为读者揭开Linux操作系统中至关重要的一环——CPU调度机制的神秘面纱。通过深入浅出地解析其工作原理,并探讨一系列创新优化策略,本文不仅增强了技术爱好者的理论知识,更为系统管理员和软件开发者提供了实用的性能调优指南,旨在促进系统的高效运行与资源利用最大化。 ###
|
4天前
|
算法 Linux 开发者
深入探究Linux内核中的内存管理机制
本文旨在对Linux操作系统的内存管理机制进行深入分析,探讨其如何通过高效的内存分配和回收策略来优化系统性能。文章将详细介绍Linux内核中内存管理的关键技术点,包括物理内存与虚拟内存的映射、页面置换算法、以及内存碎片的处理方法等。通过对这些技术点的解析,本文旨在为读者提供一个清晰的Linux内存管理框架,帮助理解其在现代计算环境中的重要性和应用。
|
2天前
|
缓存 网络协议 Linux
Linux操作系统内核
Linux操作系统内核 1、进程管理: 进程调度 进程创建与销毁 进程间通信 2、内存管理: 内存分配与回收 虚拟内存管理 缓存管理 3、驱动管理: 设备驱动程序接口 硬件抽象层 中断处理 4、文件和网络管理: 文件系统管理 网络协议栈 网络安全及防火墙管理
19 4
|
4天前
|
人工智能 算法 大数据
Linux内核中的调度算法演变:从O(1)到CFS的优化之旅###
本文深入探讨了Linux操作系统内核中进程调度算法的发展历程,聚焦于O(1)调度器向完全公平调度器(CFS)的转变。不同于传统摘要对研究背景、方法、结果和结论的概述,本文创新性地采用“技术演进时间线”的形式,简明扼要地勾勒出这一转变背后的关键技术里程碑,旨在为读者提供一个清晰的历史脉络,引领其深入了解Linux调度机制的革新之路。 ###
|
6天前
|
算法 Linux 定位技术
Linux内核中的进程调度算法解析####
【10月更文挑战第29天】 本文深入剖析了Linux操作系统的心脏——内核中至关重要的组成部分之一,即进程调度机制。不同于传统的摘要概述,我们将通过一段引人入胜的故事线来揭开进程调度算法的神秘面纱,展现其背后的精妙设计与复杂逻辑,让读者仿佛跟随一位虚拟的“进程侦探”,一步步探索Linux如何高效、公平地管理众多进程,确保系统资源的最优分配与利用。 ####
30 4
|
7天前
|
缓存 负载均衡 算法
Linux内核中的进程调度算法解析####
本文深入探讨了Linux操作系统核心组件之一——进程调度器,着重分析了其采用的CFS(完全公平调度器)算法。不同于传统摘要对研究背景、方法、结果和结论的概述,本文摘要将直接揭示CFS算法的核心优势及其在现代多核处理器环境下如何实现高效、公平的资源分配,同时简要提及该算法如何优化系统响应时间和吞吐量,为读者快速构建对Linux进程调度机制的认知框架。 ####
|
9天前
|
缓存 Linux
揭秘Linux内核:探索CPU拓扑结构
【10月更文挑战第26天】
26 1
|
9天前
|
缓存 运维 Linux
深入探索Linux内核:CPU拓扑结构探测
【10月更文挑战第18天】在现代计算机系统中,CPU的拓扑结构对性能优化和资源管理至关重要。了解CPU的核心、线程、NUMA节点等信息,可以帮助开发者和系统管理员更好地调优应用程序和系统配置。本文将深入探讨如何在Linux内核中探测CPU拓扑结构,介绍相关工具和方法。
11 0
下一篇
无影云桌面