内核的驱动和在cpu的大小端无关,内核提供一套函数来处理大小端的区别
2017-04-28 00:32
274 查看
最近在做将kernel由小端处理器(arm)向大端处理器(ppc)的移植的工作,现在kernel进入console稳定工作,基本工作已经完成,不过移植中有很多心得还是需要总结下,今天先将kernel对于大小端字节序的处理来总结下。
之前写过大小端字节序的思考,文章链接地址:http://blog.csdn.NET/skyflying2012/article/details/42065427。
根据之前的理解,字节序可以认为是处理器主观的概念,就像人如何去看待事物一样,处理器分大端和小端,对于内存的读写,只要保证数据类型一致,就不存在字节序的问题。
因此我感觉,字节序不同造成的最大差异在于对于寄存器的读写。因为外设寄存器都是小端的(根据kernel代码得出结论,下面还会在详细解释)
根据我之前字节序思考的文章,对于寄存器读写差异,有2种方案:
(1)从硬件上解决这个问题,对于32位cpu,将32根数据总线反接,但是这样对于寻址小于32位数据可能有问题,并且不能所有模块都反接(如内存),这还涉及到编译器的问题。
(2)从软件上解决这个问题,在底层读写寄存器函数中,将读/写的数据进行swap。
作为软件人员,我最关心第二种方案是否可行,因为在读写寄存器时对数据进行swap,增加了寄存器读写的复杂度,原来一条存储/加载指令可以完成的工作,现在可能需要增加一些更swap相关的指令,无法保证寄存器操作的原子性了。对于高性能,大并发的系统,可能造成竞态。
因此用最少的指令完成数据swap和r/w寄存器,才能保证Linux系统正常稳定运行。
在移植bootloader中我是将数据进行位移来完成swap,因bootloader单进程,不会存在竞态问题。
在kernel移植时很担心这个问题,但是发现kernel下已经提供了大小端处理器操作寄存器时的通用函数,就是readl/writel(以操作32位寄存器为例)。
对于driver的开发者不需要关心处理器的字节序,寄存器操作直接使用readl/writel即可。
网上有很多文章提到readl/writel,但是没有具体分析其实现。
今天就主要来分析下readl/writel如何实现高效的数据swap和寄存器读写。我们就以readl为例,针对big-endian处理器,如何来对寄存器数据进行处理。
kernel下readl定义如下,在include/asm-generic/io.h
[plain] view
plain copy
#define readl(addr) __le32_to_cpu(__raw_readl(addr))
__raw_readl是最底层的寄存器读写函数,很简单,就从直接获取寄存器数据。来看__le32_to_cpu的实现,该函数针对字节序有不同的实现,对于小端处理器,在./include/linux/byteorder/little_endian.h中,如下:
[plain] view
plain copy
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
相当于什么都没做。而对于大端处理器,在./include/linux/byteorder/big_endian.h中,如下:
[plain] view
plain copy
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
看字面意思也可以看出,__swab32实现数据翻转。等下我们就来分析__swab32的实现,精髓就在这个函数。
但是这之前先考虑一个问题,对于不同CPU,如arm mips ppc,怎么来选择使用little_endian.h还是big_endian.h的呢。
答案是,针对不同处理器平台,有arch/xxx/include/asm/byteorder.h头文件,来看下arm mips ppc的byteorder.h分别是什么。
arch/arm/include/asm/byteorder.h
[plain] view
plain copy
* arch/arm/include/asm/byteorder.h
*
* ARM Endian-ness. In little endian mode, the data bus is connected such
* that byte accesses appear as:
* 0 = d0...d7, 1 = d8...d15, 2 = d16...d23, 3 = d24...d31
* and word accesses (data or instruction) appear as:
* d0...d31
*
* When in big endian mode, byte accesses appear as:
* 0 = d24...d31, 1 = d16...d23, 2 = d8...d15, 3 = d0...d7
* and word accesses (data or instruction) appear as:
* d0...d31
*/
#ifndef __ASM_ARM_BYTEORDER_H
#define __ASM_ARM_BYTEORDER_H
#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif
#endif
arch/mips/include/asm/byteorder.h
[plain] view
plain copy
/*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
* Copyright (C) 1996, 99, 2003 by Ralf Baechle
*/
#ifndef _ASM_BYTEORDER_H
#define _ASM_BYTEORDER_H
#if defined(__MIPSEB__)
#include <linux/byteorder/big_endian.h>
#elif defined(__MIPSEL__)
#include <linux/byteorder/little_endian.h>
#else
# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
#endif
#endif /* _ASM_BYTEORDER_H */
arch/powerpc/include/asm/byteorder.h
[plain] view
plain copy
#ifndef _ASM_POWERPC_BYTEORDER_H
#define _ASM_POWERPC_BYTEORDER_H
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
#include <linux/byteorder/big_endian.h>
#endif /* _ASM_POWERPC_BYTEORDER_H */
可以看出arm mips在kernel下大小端都支持,arm mips也的确是可以选择处理器字节序。ppc仅支持big-endian。(其实ppc也是支持选择字节序的)
各个处理器平台的byteorder.h将littlie_endian.h/big_endian.h又包了一层,我们在编写driver时不需要关心处理器的字节序,只需要包含byteorder.h即可。
接下来看下最关键的__swab32函数,如下:
在include/linux/swab.h中
[plain] view
plain copy
/**
* __swab32 - return a byteswapped 32-bit value
* @x: value to byteswap
*/
#define __swab32(x) \
(__builtin_constant_p((__u32)(x)) ? \
___constant_swab32(x) : \
__fswab32(x))
宏定义展开,是一个条件判断符。
__builtin_constant_p是一个gcc的内建函数, 用于判断一个值在编译时是否是常数,如果参数是常数,函数返回 1,否则返回 0。
如果数据是常数,则__constant_swab32,实现如下:
[plain] view
plain copy
#define ___constant_swab32(x) ((__u32)( \
(((__u32)(x) & (__u32)0x000000ffUL) << 24) | \
(((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
(((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \
(((__u32)(x) & (__u32)0xff000000UL) >> 24)))
对于常数数据,采用的是普通的位移然后拼接的方法,对于常数,这样的消耗是有必要的(这是kernel的解释,不是很理解)
如果数据是运行时计算数据,则使用__fswab32,实现如下:
[plain] view
plain copy
static inline __attribute_const__ __u32 __fswab32(__u32 val)
{
#ifdef __arch_swab32
return __arch_swab32(val);
#else
return ___constant_swab32(val);
#endif
}
如果未定义__arch_swab32,则还是采用__constant_swab32方法翻转数据,但是arm mips ppc都定义了各自平台的__arch_swab32,来实现一个针对自己平台的高效的swap,分别定义如下:
arch/arm/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
__asm__ ("rev %0, %1" : "=r" (x) : "r" (x));
return x;
}
arch/mips/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
__asm__(
" wsbh %0, %1 \n"
" rotr %0, %0, 16 \n"
: "=r" (x)
: "r" (x));
return x;
}
arch/powerpc/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 value)
{
__u32 result;
__asm__("rlwimi %0,%1,24,16,23\n\t"
"rlwimi %0,%1,8,8,15\n\t"
"rlwimi %0,%1,24,0,7"
: "=r" (result)
: "r" (value), "0" (value >> 24));
return result;
}
可以看出,arm使用1条指令(rev数据翻转指令),mips使用2条指令(wsbh rotr数据交换指令),ppc使用3条指令(rlwimi数据位移指令),来完成了32 bit数据的翻转。这相对于普通的位移拼接的方法要高效的多!
其实从函数名__fswab也可以看出是要实现fast swap的。
我们反过来思考下,kernel针对小端处理器的寄存器读写数据没有做任何处理,而对于大端处理器却做了swap,这也说明了外设寄存器数据排布是小端字节序的
之前写过大小端字节序的思考,文章链接地址:http://blog.csdn.NET/skyflying2012/article/details/42065427。
根据之前的理解,字节序可以认为是处理器主观的概念,就像人如何去看待事物一样,处理器分大端和小端,对于内存的读写,只要保证数据类型一致,就不存在字节序的问题。
因此我感觉,字节序不同造成的最大差异在于对于寄存器的读写。因为外设寄存器都是小端的(根据kernel代码得出结论,下面还会在详细解释)
根据我之前字节序思考的文章,对于寄存器读写差异,有2种方案:
(1)从硬件上解决这个问题,对于32位cpu,将32根数据总线反接,但是这样对于寻址小于32位数据可能有问题,并且不能所有模块都反接(如内存),这还涉及到编译器的问题。
(2)从软件上解决这个问题,在底层读写寄存器函数中,将读/写的数据进行swap。
作为软件人员,我最关心第二种方案是否可行,因为在读写寄存器时对数据进行swap,增加了寄存器读写的复杂度,原来一条存储/加载指令可以完成的工作,现在可能需要增加一些更swap相关的指令,无法保证寄存器操作的原子性了。对于高性能,大并发的系统,可能造成竞态。
因此用最少的指令完成数据swap和r/w寄存器,才能保证Linux系统正常稳定运行。
在移植bootloader中我是将数据进行位移来完成swap,因bootloader单进程,不会存在竞态问题。
在kernel移植时很担心这个问题,但是发现kernel下已经提供了大小端处理器操作寄存器时的通用函数,就是readl/writel(以操作32位寄存器为例)。
对于driver的开发者不需要关心处理器的字节序,寄存器操作直接使用readl/writel即可。
网上有很多文章提到readl/writel,但是没有具体分析其实现。
今天就主要来分析下readl/writel如何实现高效的数据swap和寄存器读写。我们就以readl为例,针对big-endian处理器,如何来对寄存器数据进行处理。
kernel下readl定义如下,在include/asm-generic/io.h
[plain] view
plain copy
#define readl(addr) __le32_to_cpu(__raw_readl(addr))
__raw_readl是最底层的寄存器读写函数,很简单,就从直接获取寄存器数据。来看__le32_to_cpu的实现,该函数针对字节序有不同的实现,对于小端处理器,在./include/linux/byteorder/little_endian.h中,如下:
[plain] view
plain copy
#define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
相当于什么都没做。而对于大端处理器,在./include/linux/byteorder/big_endian.h中,如下:
[plain] view
plain copy
#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
看字面意思也可以看出,__swab32实现数据翻转。等下我们就来分析__swab32的实现,精髓就在这个函数。
但是这之前先考虑一个问题,对于不同CPU,如arm mips ppc,怎么来选择使用little_endian.h还是big_endian.h的呢。
答案是,针对不同处理器平台,有arch/xxx/include/asm/byteorder.h头文件,来看下arm mips ppc的byteorder.h分别是什么。
arch/arm/include/asm/byteorder.h
[plain] view
plain copy
* arch/arm/include/asm/byteorder.h
*
* ARM Endian-ness. In little endian mode, the data bus is connected such
* that byte accesses appear as:
* 0 = d0...d7, 1 = d8...d15, 2 = d16...d23, 3 = d24...d31
* and word accesses (data or instruction) appear as:
* d0...d31
*
* When in big endian mode, byte accesses appear as:
* 0 = d24...d31, 1 = d16...d23, 2 = d8...d15, 3 = d0...d7
* and word accesses (data or instruction) appear as:
* d0...d31
*/
#ifndef __ASM_ARM_BYTEORDER_H
#define __ASM_ARM_BYTEORDER_H
#ifdef __ARMEB__
#include <linux/byteorder/big_endian.h>
#else
#include <linux/byteorder/little_endian.h>
#endif
#endif
arch/mips/include/asm/byteorder.h
[plain] view
plain copy
/*
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file "COPYING" in the main directory of this archive
* for more details.
*
* Copyright (C) 1996, 99, 2003 by Ralf Baechle
*/
#ifndef _ASM_BYTEORDER_H
#define _ASM_BYTEORDER_H
#if defined(__MIPSEB__)
#include <linux/byteorder/big_endian.h>
#elif defined(__MIPSEL__)
#include <linux/byteorder/little_endian.h>
#else
# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
#endif
#endif /* _ASM_BYTEORDER_H */
arch/powerpc/include/asm/byteorder.h
[plain] view
plain copy
#ifndef _ASM_POWERPC_BYTEORDER_H
#define _ASM_POWERPC_BYTEORDER_H
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
#include <linux/byteorder/big_endian.h>
#endif /* _ASM_POWERPC_BYTEORDER_H */
可以看出arm mips在kernel下大小端都支持,arm mips也的确是可以选择处理器字节序。ppc仅支持big-endian。(其实ppc也是支持选择字节序的)
各个处理器平台的byteorder.h将littlie_endian.h/big_endian.h又包了一层,我们在编写driver时不需要关心处理器的字节序,只需要包含byteorder.h即可。
接下来看下最关键的__swab32函数,如下:
在include/linux/swab.h中
[plain] view
plain copy
/**
* __swab32 - return a byteswapped 32-bit value
* @x: value to byteswap
*/
#define __swab32(x) \
(__builtin_constant_p((__u32)(x)) ? \
___constant_swab32(x) : \
__fswab32(x))
宏定义展开,是一个条件判断符。
__builtin_constant_p是一个gcc的内建函数, 用于判断一个值在编译时是否是常数,如果参数是常数,函数返回 1,否则返回 0。
如果数据是常数,则__constant_swab32,实现如下:
[plain] view
plain copy
#define ___constant_swab32(x) ((__u32)( \
(((__u32)(x) & (__u32)0x000000ffUL) << 24) | \
(((__u32)(x) & (__u32)0x0000ff00UL) << 8) | \
(((__u32)(x) & (__u32)0x00ff0000UL) >> 8) | \
(((__u32)(x) & (__u32)0xff000000UL) >> 24)))
对于常数数据,采用的是普通的位移然后拼接的方法,对于常数,这样的消耗是有必要的(这是kernel的解释,不是很理解)
如果数据是运行时计算数据,则使用__fswab32,实现如下:
[plain] view
plain copy
static inline __attribute_const__ __u32 __fswab32(__u32 val)
{
#ifdef __arch_swab32
return __arch_swab32(val);
#else
return ___constant_swab32(val);
#endif
}
如果未定义__arch_swab32,则还是采用__constant_swab32方法翻转数据,但是arm mips ppc都定义了各自平台的__arch_swab32,来实现一个针对自己平台的高效的swap,分别定义如下:
arch/arm/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
__asm__ ("rev %0, %1" : "=r" (x) : "r" (x));
return x;
}
arch/mips/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
{
__asm__(
" wsbh %0, %1 \n"
" rotr %0, %0, 16 \n"
: "=r" (x)
: "r" (x));
return x;
}
arch/powerpc/include/asm/swab.h
[plain] view
plain copy
static inline __attribute_const__ __u32 __arch_swab32(__u32 value)
{
__u32 result;
__asm__("rlwimi %0,%1,24,16,23\n\t"
"rlwimi %0,%1,8,8,15\n\t"
"rlwimi %0,%1,24,0,7"
: "=r" (result)
: "r" (value), "0" (value >> 24));
return result;
}
可以看出,arm使用1条指令(rev数据翻转指令),mips使用2条指令(wsbh rotr数据交换指令),ppc使用3条指令(rlwimi数据位移指令),来完成了32 bit数据的翻转。这相对于普通的位移拼接的方法要高效的多!
其实从函数名__fswab也可以看出是要实现fast swap的。
我们反过来思考下,kernel针对小端处理器的寄存器读写数据没有做任何处理,而对于大端处理器却做了swap,这也说明了外设寄存器数据排布是小端字节序的
相关文章推荐
- 为什么要在kernel space 和 user space, 提供一套相同接口的驱动函数
- 【Tiny6410 And Linux】—(5.1)—RamDisk 驱动实现(内核缺省的处理函数 __make_request())——代码
- 【Tiny6410 And Linux】—(5.1)—RamDisk 驱动实现(内核缺省的处理函数 __make_request())——原理
- 内核驱动 - 混杂设备驱动 + 中断处理函数
- linux 2.6内核 字符设备驱动 相关函数
- 2.6.30.4内核cmdline常用命令行参数与相应处理函数
- linux驱动开发--copy_to_user 、copy_from_user函数实现内核空间数据与用户空间数据的相互访问
- 利用linux 内核所提供的input子系统编写字符设备驱动的步骤
- linux驱动说开去(六)--驱动模块函数与内核符号表的连接
- linux 内核(驱动)常用函数
- BPF(Berkeley Packet Filter)内核应用性能调优之 高效的驱动级网络数据包处理
- Linux 内核网络协议栈 ------ 拥塞避免处理函数 tcp_reno_cong_avoid
- 内核源码学习:套接字缓冲区提供的函数
- 预编译处理-----C语言中的宏以其和函数的区别
- Linux2.6内核驱动与2.4的区别 .
- linux驱动——内核通知链(探究i2c-dev.c 中的bus_register_notifier函数所得)
- Linux内核驱动之延时---内核超时处理【转】
- siganl与sigaction注册信号处理函数的区别
- 关于c#中的消息处理函数和vc中的消息处理函数区别
- TCHAR、wchar_t、char及字符串处理函数区别