Linux驱动开发HTR3218项目BUG(一)：驱动程序中的浮点运算问题

lagransun

已于 2023-11-29 15:02:51 修改

阅读量325

点赞数 2

分类专栏： Linux驱动开发项目笔记--htr3218驱动开发笔记文章标签： linux 驱动开发 bug

于 2023-11-04 14:20:54 首次发布

本文链接：https://blog.csdn.net/xi_xix_i/article/details/134087946

版权

Linux驱动开发项目笔记--htr3218驱动开发笔记专栏收录该内容

4 篇文章 0 订阅

订阅专栏

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xi_xix_i/article/details/134087946

一、编译环境

linux版本：4.19.9
芯片架构：arm64

二、驱动程序中的浮点运算问题

在驱动程序中，编写了如下代码：

ret_copy = copy_from_user(&led_brightness_2_args, (void*)arg, sizeof(remo_led_brightness_set_2));
led_color_args.led = led_brightness_2_args.led;
for(loop_cnt = 0; loop_cnt < 3; loop_cnt++)
{                
	if(pdata->device.led_state_remain[led_brightness_2_args.led].led_color_rgb[loop_cnt])
		led_color_args.led_color_rgb[loop_cnt] = (u8)led_brightness_2_args.brightness* 0.01 *255;
	else`
		led_color_args.led_color_rgb[loop_cnt] = 0;
}

然后在编译时报错

在这里插入图片描述
搜索引擎搜索该错误，从GCC官网了解到，-megeneral-regs-only是个GCC的ARM编译选项，具体解释如下：

-mgeneral-regs-only
    Generate code which uses only the general-purpose registers. This will prevent
    the compiler from using floating-point and Advanced SIMD registers but will
    not impose any restrictions on the assembler.

大致意思就是添加这个编译器选项后，将生成只使用通用寄存器的代码。这将阻止编译器使用浮点寄存器和高级SIMD寄存器，但不会对汇编代码使用的寄存器施加任何限制。所以如果代码中有可能使用到浮点寄存器的浮点数操作的话，代码是无法编译通过的。

这篇文章提到，使用 ARM.v8 架构的CPU 有4个运行等级(每个不同等级可以访问的寄存器的不同，就像arm v7的user mode和supervisor mode)，分别为EL0、EL1、EL2、EL3, 其中EL0 运行等级最低，基本上只能访问通用寄存器、栈指针寄存器、STR、LDR，EL3为最高等级，其中用户空间的进程运行在EL0 等级，各进程只能看到自己的信息，而感知不到其他进程，也不能访问其他进程的地址空间。而操作系统是运行在EL1 运行等级，该等级能够访问系统寄存器和配置管理进程资源。任何访问SVE、高级SIMD、浮点寄存器的操作都会被trap到更高级别的运行等级。贴一张该文章中老哥用的图：

在这里插入图片描述

所以我猜是为了实现进程隔离，让程序尽量不去操作不该操作的寄存器，默认的编译内核驱动程序的Makefile中都会加上这个编译器选项。同时这篇文章提到，Robert Love在Linux内核开发里写过：

No (Easy) Use of Floating Point
    When a user-space process uses floating-point instructions, the kernel manages the transition from integer to floating 
point mode. What the kernel has to do when using floating-point instructions varies by architecture, but the kernel 
normally catches a trap and then initiates the transition from integer to floating point mode.
    Unlike user-space, the kernel does not have the luxury of seamless support for floating point because it cannot easily 
trap itself. Using a floating point inside the kernel requires manually saving and restoring the floating point 
registers, among other possible chores. The short answer is: Don’t do it! Except in the rare cases, no floating-point 
operations are in the kernel.

大致意思就是：当用户空间进程使用浮点指令时，内核来处理从整数模式到浮点模式的转换。虽然当使用浮点指令时，内核要做的处理会随着架构的不同而不同，但是往往会使操作系统进行一次用户态与内核态的切换，然后初始化从整数到浮点模式的转换；不像用户空间，内核对浮点运算的支持并不是那么完备，因为它trap起来比较麻烦。内核中使用浮点运算需要手动保存和恢复浮点运算寄存器，以及手动处理一些其他的杂务。

这一段话我看的有点懵(也可能是我翻译的有问题)，我的理解是用户态进行浮点运算，从用户到trap到更高运行等级，并操作浮点运算寄存器，然后再返回用户态，这一套都已经优化的很好(可能是操作系统做的工作，也或者是编译器做的工作？)。但是内核驱动程序中使用浮点运算则没有这么一套完备的优化过程，所以需要代码作者手动进行一些现场的恢复和保存工作。(我不知道我理解的有没有问题，还没有更深入的研究一下，有懂的老哥可以指点一下。)

总之，就是非必要，不要在内核中进行浮点运算，这篇文章的作者确实是因为内核中使用了浮点运算操作，导致覆盖了原来用户态已储存在浮点运算寄存器的值(这么看内核如果非要用浮点运算的话，确实是要人工保存和恢复fpu寄存器)。

我想实现的功能是根据命令行参数调整led灯的亮度，在我的驱动代码中我是先进行了浮点数的运算，然后再强转为unsigned char类型，该功能确实可以先在用户空间中实现浮点数的运算，然后再取整转换为u8后把参数通过ioctl传入驱动程序。后来我也是这样做的。