嵌入式linux软件如何进行数据参数保存？

　　大多数软件开发都会涉及到数据参数的保存与读取，小至运行的单片机的软件，大至操作系统级别的软件（如linux，windows，mac），均会有专门的子程序或者模块进行参数的保存和读取。不同的平台下开发，参数的保存与读取会存在一定的差异化，例如，单片机下，保存参数是写入eeprom或者 rom，windows和linux下的软件则会以配置文件的形式保存参数。下面以我以前在工作中所遇到情况，重点写写嵌入式linux软件是如何进行的数据参数的保存。

　　一 以二进制数据保存参数。

　　以二进制形式保存参数是很是常见的一种方案，也是很多项目组用于保存参数的一种方案。以我们现有的软件平台中的方案为例吧。

　　我们的软件平台基于嵌入式ｌｉｎｕｘ，　flaｓｈ芯片容量是16M，flash 芯片被分为了五个区，如下所示， 其中parameter 分区用于数据参数的存储。

　　| uboot | kernel | rootfs | app | parameter |

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

　　uboot 分区 对应 设备文件/dev/mtdblock0

　　kernel 分区 对应 设备文件/dev/mtdblock1

　　rootfs 分区 对应 设备文件/dev/mtdblock2

　　app 分区 对应 设备文件/dev/mtdblock3

　　parameter 分区 对应 设备文件/dev/mtdblock4

　　假设我们想要保存用户名与密码。

　　1 定义一个结构体， 结构体成员包含用户名与密码

　　struct _Parameter{

　　char usename［16］;

　　char password［16］;

　　};

　　int fd = -1;

　　fd = open（/dev/mtdblock5， O_RDWR）;

　　struct _Parameter sys_parameter;

　　2 填充sys_parameter的成员usename和password，假若username为dodolook，密码为123456

　　strncpy（sys_parameter.username， “dodolook”， 16）;

　　strncpy（sys_parameter.password， “123456”， 16）;

　　3 将sys_parameter以二进制的形式写入flash分区5的映射的设备文件/dev/mtdblock4.

　　write（fd， &sys_parameter， sizeof（struct _Parameter））;

　　参数的读取

　　从设备文件/dev/mtdblock4读取sizeof（struct _Parameter） 大小的字节到所定义的参数结构体sys_parameter的变量地址。

　　int fd = -1;

　　fd = open（/dev/mtdblock5， O_RDWR）;

　　read（fd， &sys_parameter， sizeof（struct _Parameter））;

　　上述的保存参数的过程， 与单片机开发的参数保证颇有几份相似之处， 早期的嵌入式软件开发工程师大多有过单片机软件开发的经历， 在单片机中，参数会写入一个eeprom芯片（部分单片机自身集成eeprom芯片），当有着单片机开发经历的工程师转行到嵌入式软件开发，不可避免的沿续了以前的工作经验，也许这便是我们系统中数据参数存储方案的来历。

　　二进制数据保存参数的方案的确存在速度的优势， 但同时也存在着以下几个不是避免的问题。

　　1 对现有数据进行扩展极为不便。

　　例如 在设计时， 我们理所当然的想到，16个字符完全足够能够显示一个用户名，假设，客户提一个特别变态的需求，需要输入17个字符。怎么办？动之以情，晓之以理，劝劝客户别提这么变态的需求。可人客户不听，怎么办？只能重新定义结构体。这下更好了， 新的参数结构体与早先的软件不兼容。怎么办？定义客户编绎开关，只有此客户才用到此编绎开关。 行，问题是解决了，随意的添加工编绎开关，又为后期的维护埋下的定时炸弹。

　　2 无法直接查看编缉参数。

　　保存的参数对我们来说是不透明的， 不可交互的。 在软件开发， 我们常常遇到由于参数区数据被破坏而引发的bug， 我们为会拷贝参数区到一个文件 ，与正常的参数区二进制进行对比， 以确定参数区是否被破坏。 存入参数区的数据为二进制数据， 二进制式数据对我们来说， 几乎不具有可读性，进而影响到软件的可维护性。