CN101685450B

CN101685450B - 一种在嵌入式操作系统中实现数据库功能的方法

Info

Publication number: CN101685450B
Application number: CN2008101671116A
Authority: CN
Inventors: 陆波波; 樊旭军; 张中博; 丁华
Original assignee: BYD Co Ltd
Current assignee: BYD Co Ltd
Priority date: 2008-09-27
Filing date: 2008-09-27
Publication date: 2011-08-24
Anticipated expiration: 2028-09-27
Also published as: CN101685450A

Abstract

本发明公开了一种在嵌入式操作系统中实现数据库功能的方法，包括：A、在嵌入式操作系统中移植一套与嵌入式数据库匹配的内存操作接口，所述移植的内存操作接口的内存操作方式与所述嵌入式操作系统的内存操作方式不同；B、在嵌入式操作系统的文件系统API上映射嵌入式数据库的文件系统API；C、将所述嵌入式数据库的临时文件重定向到预设的临时目录下，并在所述嵌入式数据库使用结束后删除所述预设的临时目录下的临时文件；D、将所述嵌入式数据库的多任务功能接口失效。应用本发明能够以较低的成本在嵌入式操作系统中实现数据库功能。

Description

一种在嵌入式操作系统中实现数据库功能的方法

技术领域

本发明涉及嵌入式技术，特别涉及一种在嵌入式操作系统中实现数据库功能的方法。

背景技术

目前，嵌入式技术正广泛应用于人们生产、生活的各个领域，基于各种嵌入式操作系统平台的应用软件开发也在如火如荼地进行。这些应用软件在实现其相应的功能时，可能需要对数据进行各种灵活的操作，这就需要嵌入式操作系统中提供数据库的功能，以供这些应用软件调用。

在嵌入式操作系统中实现数据库功能的一个最省时、省力的方法就是将现有技术中已经存在的某种嵌入式数据库移植到该嵌入式操作系统中。然而，所述移植并不是简单地将嵌入式数据库的源代码复制到嵌入式操作系统中即可完成，而是需要解决许多相关的技术问题才能实现。在移植过程中可能存在的技术问题包括：内存操作接口匹配问题、内存使用冲突问题、文件系统应用编程接口(API)匹配问题、临时文件的处理问题、单任务/多任务问题等。

下面以在Nucleus嵌入式操作系统中移植SQlite嵌入式数据库为例，说明成功完成所述移植需要解决的技术问题：

1、内存操作接口匹配问题：Nucleus操作系统中的内存操作接口不能满足SQlite对内存操作接口的要求，需要一套专供SQlite使用的内存操作接口，但又不能与原有内存使用相冲突。

2、文件系统API匹配问题：基于Nuclues操作系统的嵌入式平台上提供的文件系统API如何满足SQlite移植的要求。

3、临时文件的处理问题：嵌入式数据库SQlite运行后将产生许多临时文件，像Linux和Windows这样的高级操作系统将自动清除它们，但是嵌入式操作系统通常没有自动清除的功能。

4、单任务/多任务的问题：嵌入式数据库SQlite需要提供多任务级或多线程级的数据保护以及互斥等接口，这些在高级操作系统上都是默认提供的，甚至是从内核上得到支持的，但是，Nucleus是基于单任务的操作系统，在现有Nucleus上还没有多任务级或多线程级的接口。

上述技术问题的存在阻碍了嵌入式操作系统对数据库功能的支持，进而阻碍了各种基于嵌入式操作系统平台的应用软件的快速开发。

发明内容

有鉴于此，本发明的主要目的在于提供一种在嵌入式操作系统中实现数据库功能的方法，实现以较低的成本在嵌入式操作系统中提供数据库功能。

为达到上述目的，本发明实施例提供了一种在嵌入式操作系统中实现数据库功能的方法，包括：

A、在嵌入式操作系统中移植一套与嵌入式数据库匹配的内存操作接口，所述移植的内存操作接口的内存操作方式与所述嵌入式操作系统的内存操作方式不同；

B、在嵌入式操作系统的文件系统应用编程接口API上映射嵌入式数据库的文件系统API；

C、将所述嵌入式数据库的临时文件重定向到预设的临时目录下，并在所述嵌入式数据库使用结束后删除所述预设的临时目录下的临时文件；

D、将所述嵌入式数据库的多任务功能接口失效。

由上述技术方案可见，本发明提供的在嵌入式操作系统中实现数据库功能的方法，通过在嵌入式操作系统中移植一套与该嵌入式操作系统的内存操作方式不同的内存操作接口，解决了嵌入式数据库移植过程中的内存操作接口匹配；通过在嵌入式操作系统的文件系统API上映射嵌入式数据库的文件系统API，解决了文件系统API匹配问题；通过将嵌入式数据库的临时文件重定向到预设的临时目录下，并在嵌入式数据库使用结束后删除预设的临时目录下的临时文件，解决了临时文件的处理问题；通过将嵌入式数据库的多任务功能接口失效，解决了单任务/多任务的问题，从而实现了以较低的成本在嵌入式操作系统中提供数据库功能。同时，也缩短了在嵌入式操作系统中开发应用软件的周期。

附图说明

图1为本发明在嵌入式操作系统中实现数据库功能的方法流程示意图；

图2示出了本发明实施例中文件定位接口的实现流程示意图；

图3示出了本发明实施例中删除临时目录下的所有临时文件的流程示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一步详细说明。

本发明的主要思想是分别从内存操作接口匹配问题、内存使用冲突问题、文件系统API匹配问题、临时文件的处理问题、单任务/多任务问题的角度出发，提出解决相应问题的技术方案，从而将嵌入式数据库移植到嵌入式操作系统，实现以较低的成本在嵌入式操作系统中提供数据库功能。

对应于上述主要思想，本发明提供了一种如图1所示的在嵌入式操作系统中实现数据库功能的方法，参见图1，该方法包括：

步骤101：在嵌入式操作系统中移植一套与嵌入式数据库匹配的内存操作接口，所述移植的内存操作接口的内存操作方式与所述嵌入式操作系统的内存操作方式不同；

步骤102：在嵌入式操作系统的文件API上映射嵌入式数据库的文件系统API；

步骤103：将所述嵌入式数据库的临时文件重定向到预设的临时目录下，并在所述嵌入式数据库使用结束后删除所述预设的临时目录下的临时文件；

步骤104：将所述嵌入式数据库的多任务功能接口失效。

至此，结束本发明在嵌入式操作系统中实现数据库功能的方法。

下面通过一个具体示例，说明本发明技术方案的具体实施方式。

本示例主要阐述如何在德州仪器(TI)Locosto平台上移植开源嵌入式数据库SQlite3.3.6。TI Locosto平台是一款基于Nucleus Plus1.15的嵌入式手机平台。

现有的参考移植方案都是基于高级操作系统。在高级操作系统中，有完善的接口以及操作系统内核本身对相关功能的有力支持，但是在嵌入式操作系统中，这些都不是现成的。下面从前面提到的移植的四个方面具体展开：

1、内存操作接口匹配问题

SQlite嵌入式数据库关于内存方面需要提供以下接口函数：内存分配(sqlite3OsMalloc)、内存重新分配(sqlite3OsRealloc)、内存释放(sqlite3OsFree)和分配大小(sqlite3OsAllocationSize)，加上SQlite源码中需要的接口函数：内存分配(malloc)、内存释放(free)和内存重新分配(realloc)，共七个接口函数。

其中，sqlite3OsAllocationSize接口用SQlite默认提供的sqlite3GenericAllocationSize接口即可实现。malloc、free和realloc都是标准的C库函数，但是TI平台并没有提供，TI提供的内存操作接口只能够实现malloc和free的功能，无法实现realloc功能。而现实SQlite的源代码中有很多地方均需使用realloc函数，因此，需要移植一套新的内存操作接口以满足对realloc的需求但同时不能影响TI平台中原有内存的使用。

TI平台采用基于内存池(POOL)的内存操作方式，因此，所移植的新的内存操作接口需要避免采用基于POOL的内存操作方式。本示例中，解决办法是移植采用基于大数组方式而非内存池POOL方式的内存操作接口。大数组方式的内存接口是指利用数组开辟一段非常大的内存空间，所有内存的获取、释放都是基于这段内存空间，这样就可以避免与内存池方式操作同一块内存区域，保证原有使用内存池方式的内存操作接口的程序可以正常工作。

具体的移植过程是将基于大数组方式的内存分配、内存重新分配和内存释放三个接口封装到三个统一接口当中，如下面例子中的：sqlite3BalMalloc、sqlite3BalRealloc和sqlite3BalFree，然后，在SQlite内部进行如下重新映射：

#define malloc sqlite3BalMalloc

#define free sqlite3BalFree

#define realloc sqlite3BalRealloc

#define sqlite3OsMalloc sqlite3BalMalloc

#define sqlite3OsRealloc sqlite3BalRealloc

#define sqlite3OsFree sqlite3BalFree

#define sqlite3OsAllocationSize sqlite3GenericAllocationSize

2、文件系统API匹配问题

文件系统API的移植主要是按照SQlite对每个文件操作接口的移植要求在TI参考的文件系统API上做映射。需要解决的问题主要包括：

1)系统输入输出接口(I/O，Input/Output)移植问题

输入输出方法(IoMethod)中包含的接口是需要移植的、基于POSIX的文件系统接口：

static const IoMethod sqlite3BalIoMethod＝{

balFileClose， //文件关闭

balOpenDirectory， //打开目录

balFileRead， //文件读

balFileWrite， //写

balSeek， //文件定位

balFileTruncate， //文件截取

balFlush， //文件同步

balSetFullSync， //设置是否完全同步

balFileHandle， //获取文件句柄

balFileSize， //文件大小

balLock， //文件锁

balUnlock， //文件解锁

balLockState， //锁状态

balCheckReservedLock， //检查预留锁

}；

其中，文件的打开、关闭，以及获取文件句柄等接口直接进行移植即可，需要注意的是文件读写接口。由于嵌入式文件系统读取文件或写入文件的速度受主频的限制不能很快，因此，需要根据嵌入式操作系统的主频大小设置段长上限，对嵌入式数据库的文件读写接口的操作数据按照所设置的段长上限进行分段处理。例如：可以设置段长上限为512字节或1024字节，当文件读写接口的操作数据大于512字节或1024字节时，对所述数据进行分段处理。

其次，文件定位接口(balSeek)和文件截取接口(balFileTruncate)也需要进行一些处理才能移植。

由于TI的文件系统中不能定位一个比当前文件大小大的位置，因此，本发明提出了一种修改文件定位接口的方案，经修改后的文件定位接口的工作过程如下：首先，根据所述文件定位接口中携带的位置参数，然后，判断当前被操作文件的大小是否小于所述位置参数，若小于，则分配(位置参数-当前被操作文件大小)字节的内存，定位到当前被操作文件的结束位置，并将从所述结束位置开始的(位置参数-当前被操作文件大小)字节的内容写入当前被操作文件，释放所述分配的内存，从当前被操作文件的开始处向后定位位置参数对应的字节数；若不小于，则从当前被操作文件的开始处向后定位位置参数对应的字节数。图2示出了本发明实施例中文件定位接口的实现流程示意图。参见图2，该文件定位接口的实现过程包括：

步骤201：获取当前被操作文件的大小，记为fs。

步骤202：判断文件定位接口中携带的位置参数(记为ft)是否大于当前被操作文件的大小fs，若大于，则继续执行步骤203；否则，跳到步骤207。

步骤203：分配(ft-fs)字节内存，并将所述分配的内存置零。

本步骤中，若内存分配失败，则返回错误，并结束本方法。

步骤204：定位到当前被操作文件的结束位置。

步骤205：将从所述结束位置开始的(ft-fs)字节的内容写入当前被操作文件。

步骤206：释放步骤203所分配的内存。

步骤207：从当前被操作文件的开始处向后定位ft大小，正确返回。

至此，结束本实施例中文件定位接口的实现流程。

对于文件截取函数的移植，可以按照如下步骤进行：

第1步：定位到当前被操作文件的起始位置。

第2步：在所述起始位置调用TI平台的文件系统API中的文件截取接口函数，若调用成功则继续执行第3步；否则，跳到第4步。

第3步：返回调用结果，结束本流程。

第4步：定位到当前被操作文件的结束位置，并返回错误，结束本流程。

此外，由于本示例中使用的Flash是Nor-Flash，它们没有缓存，而是直接写入物理系统中，因此，上述balFlush、balSetFullSync等需要缓存数据的接口函数无需移植，直接将需要缓存数据的文件系统API失效即可。将API失效的方法可以是：在该API函数中增加直接返回成功的代码。同样地，对于balLock、balUnlock、balLockState和balCheckReservedLock这四个针对多任务的文件系统API，由于TI平台是基于单任务的操作系统，因此，直接将其失效即可。

2)SQlite文件操作接口移植问题

在SQlite中存在一些非标准的文件系统操作接口。其中，以可读写方式打开文件接口和以只读方式打开文件接口可以用传入不同的mode值来移植，但是TI本身的文件系统不支持互斥打开，因此，对于SQlite中的文件互斥打开接口，需要在该文件互斥打开接口的开始执行处增加如下操作：

第1步：根据该文件互斥打开接口中携带的文件名判断该文件是否已存在，若已存在则继续执行第2步；否则，跳到第3步。

第2步：删除该文件。

第3步：创建一个名字为所述文件名的文件，正确返回。

对于判断文件是否存在的接口函数(sqlite3OsFileExists)、以及判断文件是否可写的接口函数(sqlite3OsIsDirWritable)可以通过文件属性(FileAttrib)接口函数来移植。对于同步目录接口函数(sqlite3OsSyncDirectory)，由于本示例使用的是Nor-Flahs，因此，无需移植，直接返回成功即可。删除接口函数(sqlite3OsDelete)可以采用TI的文件系统API中的删除文件接口进行实现。按照上述方法进行移植之后，可以得到如下所示的映射关系(映射关系中，右边是最终被映射的移植完的函数)：

#define sqlite3OsOpenReadWrite sqlite3BalOpenReadWrite

#define sqlite3OsOpenExclusive sqlite3BalOpenExclusive

#define sqlite3OsOpenReadOnly sqlite3BalOpenReadOnly

#define sqlite3OsDelete sqlite3BalDelete

#define sqlite3OsFileExists sqlite3BalFileExists

#define sqlite3OsFullPathname sqlite3BalFullPathname

#define sqlite3OsIsDirWritable sqlite3BalIsDirWritable

#define sqlite3OsSyncDirectory sqlite3BalSyncDirectory

3、临时文件的处理问题

SQlite在运行过程中将产生临时文件，这些临时文件通常置于TI系统根目录的tmp目录下。对于高级操作系统来说，这些临时目录下的文件将在使用它的应用程序运行结束后由系统自动删除，但是，Nucleus中这些删除操作系统不能自动完成。为此，需要解决以下两个问题：

1)将SQlite使用的临时文件重定向到某个预先生成的临时目录下。本示例中，所述预先生成的临时目录命名为/tmp。

2)在SQlite使用结束后，删除临时目录中所有的临时文件。

针对上述问题1)，需要修改sqlite3OsTempFileName对应的映射后的函数，将/tmp目录作为其工作的主目录。具体的移植流程包括：

第1步：判断/tmp目录是否存在，如果不存在，则继续执行第2步；否则，跳到第3步。

第2步：调用文件系统创建目录的函数创建/tmp目录，若创建失败，则错误返回，若创建成功，则继续执行第3步。

第3步：调用sqlite3Randomness为SQlite生成随机函数名，并返回文件名。所述返回的文件名应该是包含临时目录名的全路径名。

针对上述问题2)，需要开发一个专用于删除临时目录下的所有临时文件的函数。图3示出了本发明实施例中删除临时目录下的所有临时文件的流程示意图。参见图3，该流程包括：

步骤301：判断/tmp目录是否存在，若存在，则继续执行步骤302；否则，返回错误，并结束本流程。

步骤302：打开/tmp目录，若成功打开，则继续执行步骤303；否则，返回错误，并结束本流程。

步骤303：申请分配一段内存buffer，用于存放文件名。例如：可以申请256字节的内存。

在步骤303之后，循环执行步骤304～307的操作，直至跳出循环：

步骤304：调用读目录函数，将读目录函数返回的文件名写入buffer，并判断写入是否成功，若成功，则继续执行步骤305，否则，跳出所述循环，跳到步骤308。

步骤305：判断当前目录是否为根目录，即判断当前目录是否为“.”或“..”目录，若是，则跳到步骤304；否则，继续执行步骤306。

步骤306：在buffer中插入所读到的目录名。

步骤307：删除buffer中对应为全路径名的文件。

步骤308：关闭/tmp目录。

步骤309：释放步骤303所分配的内存，并正确返回，结束本流程。

图3所示流程可以在SQlite的关闭函数(sqlite3_close)中调用，也可以在应用程序退出时调用。

4、单任务/多任务的问题

SQlite3.3.6默认支持多任务。SQlite3.3.6中的许多多任务接口都是直接调用高级操作系统中已经存在的接口，例如：保护、回复任务或线程相关的数据、锁机制等；然而，Nucleus上并未提供这些接口。为此，有两种解决方案，要么实现这些高级操作系统提供的接口，要么将SQlite改成基于单任务的。考虑到Nucleus中，单任务即可满足实际应用的需要，因此，本示例选择后者。具体的实现过程包括：

第1步：将SQlite中的File结构精简为：

struct balFile{

IoMethod const*pMethod； /*Must be first*/

uint32h； /*Handle for accessing the file*/

unsigned char locktype； /*Type of lock currently held on this file*/

short sharedLockByte； /*Randomly chosen byte used as a shared lock*/

bLock local； /*Locks obtained by this instance of balFile*/

}；

第2步：将对应于多任务的文件系统API全部失效。

具体地，将创建锁(CreateLock)、销毁锁(DestroyLock)、加查预留锁(CheckReservedLock)、锁(Lock)、解锁(UnLock)、锁文件(LockFile)和解锁文件(UnLockFile)这七个接口中的功能性代码全部删除，并直接返回成功。锁状态(LockState)接口函数无需修改，锁文件(LockFileEx)函数可以去掉。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种在嵌入式操作系统中实现数据库功能的方法，其特征在于，包括：

D、将所述嵌入式数据库的多任务功能接口失效。

2.根据权利要求1所述的方法，其特征在于，所述嵌入式操作系统的内存操作方式为：基于内存池的内存操作方式；

所述移植的内存操作接口的内存操作方式为：基于大数组的内存操作方式。

3.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：文件读写接口；

所述步骤B包括：根据所述嵌入式操作系统的主频大小设置段长上限，对所述嵌入式数据库的文件读写接口的操作数据按照所述段长上限进行分段处理。

4.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：文件定位接口；

所述步骤B还包括：将所述文件定位接口修改为：根据所述文件定位接口中携带的位置参数，判断当前被操作文件的大小是否小于所述位置参数，若小于，则分配位置参数与当前被操作文件大小之差个字节的内存，定位到当前被操作文件的结束位置，并将从所述结束位置开始的位置参数与当前被操作文件大小之差个字节的内容写入当前被操作文件，释放所述分配的内存，从当前被操作文件的开始处向后定位位置参数对应的字节数；若不小于，则从当前被操作文件的开始处向后定位位置参数对应的字节数。

5.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：文件截取接口；

所述步骤B还包括：将所述文件截取接口修改为：定位到当前被操作文件的起始位置，在所述起始位置调用所述嵌入式操作系统的文件系统API中的文件截取接口，若调用成功则返回相应的调用结果，否则，定位到当前被操作文件的结束位置，并返回错误。

6.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：需要缓存数据的文件系统API；

所述步骤B还包括：将所述需要缓存数据的文件系统API失效。

7.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：对应于多任务的文件系统API；

所述步骤B还包括：将所述对应于多任务的文件系统API失效。

8.根据权利要求1所述的方法，其特征在于，所述嵌入式数据库的文件系统API包括：文件互斥打开接口；

所述步骤B还包括：在所述文件互斥打开接口的开始执行处增加如下操作：根据所述文件互斥打开接口中携带的文件名判断该文件是否已存在，若已存在则删除所述文件，并创建一个名字为所述文件名的文件；否则，创建一个名字为所述文件名的文件。

9.根据权利要求1至8任一项所述的方法，其特征在于，所述嵌入式操作系统为：Nucleus嵌入式操作系统；

所述嵌入式数据库为：SQlite嵌入式数据库。