linux源码分析之字节序(4)-- little_endian.h

本节主要分析小端字节顺序。

首先,我们要回顾上一节讲过的大端、小端的概念:

字节顺序是指占内存多于一个字节类型的数据在内存中的存放顺序,通常有小端、大端两种字节顺序。小端字节序指低字节数据存放在内存低地址处,高字节数据存放在内存高地址处;大端字节序是高字节数据存放在低地址处,低字节数据存放在高地址处。基于X86平台的PC机是小端字节序的,而有的嵌入式平台则是大端字节序的。因而对int、uint16、uint32等多于1字节类型的数据,在这些嵌入式平台上应该变换其存储顺序。通常我们认为,在空中传输的字节的顺序即网络字节序为标准顺序,考虑到与协议的一致以及与同类其它平台产品的互通,在程序中发数据包时,将主机字节序转换为网络字节序,收数据包处将网络字节序转换为主机字节序。

其实big endian是指低地址存放最高有效字节(MSB),而little endian则是低地址存放最低有效字节(LSB)。

接下来,我们来看看 路径  include/linux/byteorder 下的文件 little_endian.h

--------------------------------------------------------------------------------------------------------------------------------

#ifndef _LINUX_BYTEORDER_LITTLE_ENDIAN_H

#define _LINUX_BYTEORDER_LITTLE_ENDIAN_H

#ifndef __LITTLE_ENDIAN

#define __LITTLE_ENDIAN 1234

#endif

#ifndef __LITTLE_ENDIAN_BITFIELD

#define __LITTLE_ENDIAN_BITFIELD

#endif

#include <linux/types.h>

#include <linux/swab.h>

#define __constant_htonl(x) ((__be32)___constant_swab32((x)))       //网络字节序与主机字节序的转换函数

#define __constant_ntohl(x) ___constant_swab32((__be32)(x))

#define __constant_htons(x) ((__be16)___constant_swab16((x)))

#define __constant_ntohs(x) ___constant_swab16((__be16)(x))

#define __constant_cpu_to_le64(x) ((__le64)(__u64)(x))

#define __constant_le64_to_cpu(x) ((__u64)(__le64)(x))

#define __constant_cpu_to_le32(x) ((__le32)(__u32)(x))

#define __constant_le32_to_cpu(x) ((__u32)(__le32)(x))

#define __constant_cpu_to_le16(x) ((__le16)(__u16)(x))

#define __constant_le16_to_cpu(x) ((__u16)(__le16)(x))

#define __constant_cpu_to_be64(x) ((__be64)___constant_swab64((x)))

#define __constant_be64_to_cpu(x) ___constant_swab64((__u64)(__be64)(x))

#define __constant_cpu_to_be32(x) ((__be32)___constant_swab32((x)))

#define __constant_be32_to_cpu(x) ___constant_swab32((__u32)(__be32)(x))

#define __constant_cpu_to_be16(x) ((__be16)___constant_swab16((x)))

#define __constant_be16_to_cpu(x) ___constant_swab16((__u16)(__be16)(x))

#define __cpu_to_le64(x) ((__le64)(__u64)(x))

#define __le64_to_cpu(x) ((__u64)(__le64)(x))

#define __cpu_to_le32(x) ((__le32)(__u32)(x))

#define __le32_to_cpu(x) ((__u32)(__le32)(x))

#define __cpu_to_le16(x) ((__le16)(__u16)(x))

#define __le16_to_cpu(x) ((__u16)(__le16)(x))

#define __cpu_to_be64(x) ((__be64)__swab64((x)))

#define __be64_to_cpu(x) __swab64((__u64)(__be64)(x))

#define __cpu_to_be32(x) ((__be32)__swab32((x)))

#define __be32_to_cpu(x) __swab32((__u32)(__be32)(x))

#define __cpu_to_be16(x) ((__be16)__swab16((x)))

#define __be16_to_cpu(x) __swab16((__u16)(__be16)(x))

static __inline__ __le64 __cpu_to_le64p(const __u64 *p)

{

return (__le64)*p;

}

static __inline__ __u64 __le64_to_cpup(const __le64 *p)

{

return (__u64)*p;

}

static __inline__ __le32 __cpu_to_le32p(const __u32 *p)

{

return (__le32)*p;

}

static __inline__ __u32 __le32_to_cpup(const __le32 *p)

{

return (__u32)*p;

}

static __inline__ __le16 __cpu_to_le16p(const __u16 *p)

{

return (__le16)*p;

}

static __inline__ __u16 __le16_to_cpup(const __le16 *p)

{

return (__u16)*p;

}

static __inline__ __be64 __cpu_to_be64p(const __u64 *p)

{

return (__be64)__swab64p(p);

}

static __inline__ __u64 __be64_to_cpup(const __be64 *p)

{

return __swab64p((__u64 *)p);

}

static __inline__ __be32 __cpu_to_be32p(const __u32 *p)

{

return (__be32)__swab32p(p);

}

static __inline__ __u32 __be32_to_cpup(const __be32 *p)

{

return __swab32p((__u32 *)p);

}

static __inline__ __be16 __cpu_to_be16p(const __u16 *p)

{

return (__be16)__swab16p(p);

}

static __inline__ __u16 __be16_to_cpup(const __be16 *p)

{

return __swab16p((__u16 *)p);

}

#define __cpu_to_le64s(x) do { (void)(x); } while (0)

#define __le64_to_cpus(x) do { (void)(x); } while (0)

#define __cpu_to_le32s(x) do { (void)(x); } while (0)

#define __le32_to_cpus(x) do { (void)(x); } while (0)

#define __cpu_to_le16s(x) do { (void)(x); } while (0)

#define __le16_to_cpus(x) do { (void)(x); } while (0)

#define __cpu_to_be64s(x) __swab64s((x))

#define __be64_to_cpus(x) __swab64s((x))

#define __cpu_to_be32s(x) __swab32s((x))

#define __be32_to_cpus(x) __swab32s((x))

#define __cpu_to_be16s(x) __swab16s((x))

#define __be16_to_cpus(x) __swab16s((x))

#endif /* _LINUX_BYTEORDER_LITTLE_ENDIAN_H */

-----------------------------------------------------------------------------------------------------------------------------------------

总结:

本节主要分析了小端字节序定义,以及网络字节序与主机字节序的转换函数。

补充:

两大CPU派系:Motorola的PowerPC系列和Intel的x86系列。

PowerPC系列采用big endian方式存储数据,而x86系列则采用little endian方式存储数据。(这在  linux源码分析之字节序(4) 中有过分析)

时间: 2024-12-09 11:11:19

linux源码分析之字节序(4)-- little_endian.h的相关文章

linux源码分析之字节序(5)-- swab.h

在linux源码分析之字节序(3).linux源码分析之字节序(4)中都有看到,源码中包含了 #include <linux/swab.h> 该头函数里面介绍了字节交换的具体方法.我们来看看具体代码: --------------------------------------------------------------------------------------------------------------- #ifndef _LINUX_SWAB_H #define _LINUX

linux源码分析之字节序(2)-- types.h

这一节主要讲linux的数据类型,主要是为了方便理解接下来将大端.小段字节序定义的源码. 首先,来看看 include/linux/types.h 源码: ------------------------------------------------------------------ #ifndef _LINUX_TYPES_H #define _LINUX_TYPES_H #include <asm/types.h> #ifndef __ASSEMBLY__ #include <l

linux源码分析之字节序(1)-- byteorder.h

首先我们要知道的一点是:在Linux内核中,不同CPU里面,各自的字节序定义都不同. 本次用于分析的 Linux 内核版本为: linux--3.0.0-12. arch/XXX/include/asm/byteorder.h:不同CPU(XXX)的字节序定义 1)ARM(XXX=arm): #ifdef __ARMEB__ #include <linux/byteorder/big_endian.h> #else #include <linux/byteorder/little_end

linux源码分析之字节序(3)-- big_endian.h

本节主要分析大端字节顺序. 首先,我们要理解大端.小端的概念: 字节顺序是指占内存多于一个字节类型的数据在内存中的存放顺序,通常有小端.大端两种字节顺序.小端字节序指低字节数据存放在内存低地址处,高字节数据存放在内存高地址处:大端字节序是高字节数据存放在低地址处,低字节数据存放在高地址处.基于X86平台的PC机是小端字节序的,而有的嵌入式平台则是大端字节序的.因而对int.uint16.uint32等多于1字节类型的数据,在这些嵌入式平台上应该变换其存储顺序.通常我们认为,在空中传输的字节的顺序

linux源码分析之位长定义 -- bitsperlong.h

我们知道,在Linux内核中,不同CPU里面,不同CPU的字节序定义不同. 本节年内容主要是讲的是:不同CPU里面,各自的位长定义也是不同. 本次用于分析的 Linux 内核版本为: linux--3.0.0-12. arch/XXX/include/asm/bitsperlong.h:不同CPU(XXX)的位长定义 1)ARM(XXX=arm): #include <asm-generic/bitsperlong.h> (2)PowerPC(XXX=powerpc) #ifndef __AS

linux源码分析之IP(1) -- ip.h

在IP层的分组叫做数据报.本节主要介绍数据报的格式,以及在 linux 中是如何定义IP分组头格式. 首先,数据报的格式如下: 其中: 1.版本:有版本4和版本6 2.首部长度:定义数据报的总长度,以4字节为单位计算.首部长度在 20~60字节之间. 3.服务类型:前三位为优先位,后面两位为TOS位,最后一位没有使用. 4.总长度:定义以字节计的数据报总长度(首部加上数据),故数据报长度限制为65535 5.标识:标志从源主机发出的数据报.该字段和Flags和Fragment Offest字段联

linux源码分析之节拍率 -- param.h

系统定时器频率是通过静态预处理定义的,在系统启动时按照 HZ 值对硬件进行设置.体系结构不同,HZ的值也不同.对于某些体系结构,甚至是机器不同,HZ的值也会不同. 内核在 <asm/param.h> 中定义了 HZ 的值.我们接下来就来比较一下具体源码: 1.arm 体系结构(文件路径:/arm/include/asm/param.h) #ifndef __ASM_PARAM_H #define __ASM_PARAM_H #ifdef __KERNEL__ # define HZ CONFI

linux源码分析 - 进程

本文为原创,转载请注明:http://www.cnblogs.com/tolimit/ 最近在回想一些知识点的时候,觉得对进程这一块有些模糊,特别写一篇随笔对进程信息进行巩固和复习. 程序和进程 以我个人的理解就是,程序是一段二进制编码甚至是一个简单的可执行文件,而当程序这段二进制编码放入内存运行时,它就会产生一个或多个进程. CPU时间片 对于CPU来说,它的工作就是不停地执行指令,而由于CPU执行指令的速度非常快,它可以用5ms的时间专门用于执行进程A,5ms的时间专门用于执行进程B,5ms

第一次作业:深入Linux源码分析其进程模型

一.进程 1.进程的概念 (1)进程:Process,是计算机中的程序关于某数据集合上的一次运行活动,是系统进行资源分配和调度的基本单位,是操作系统结构的基础. (2)进程由程序.数据和进程控制块PCB组成.当系统创建一个进程时,实际上是建立一个PCB.当进程消失时,实际上是撤销PCB.在进程活动的整个生命周期内,系统通过PCB对进程进行管理和调度. 2.查看进程状态 (1)ps指令(常用组合:aux.ef.eFH.-eo.axo) (2)示例 # ps  aux:显示所有与终端有无关联的进程信