Sarah uttered:
Thank you for your advice.
If I skip the functionality of file locking, that is to say, in my
project, I do not need to use the functionality of file locking, then
which approach will be easier for me to wrap my self-defined file system
to a set of standard interfaces？
One is to wrap it to fit os_win.c;
The other one is to wrap it to fit os_unix.c;
Being a UNIX guy, I'd recommend UNIX. If your background is Windows, you
may find it easier to implement a Win32 like API.
Basically, without locking, the two should be broadly similar.
----- Original Message -----
From: "Christian Smith" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, June 21, 2006 7:04 PM
Subject: Re: [sqlite] How to port SQLite to a uc/os-II OS with customized file
system?
Ҷ uttered:
Hi,all
I'm trying to bulid a database engine based on uc/os-II RTOS with my own
customized file system(similar with FAT16, but not exactly the same). I
find that SQLite is a good choice.
I have read the SQLite source code for several days, but I still have no
idea where I should begin with.
SQLite is a db engine totally based on disk file. So I guess most of my
future work should be to wrap my self-defined file system to have the
same interface as needed in os_win.c. Is it correct?
Could anyone give me some advice?
Implement the interface defined by "struct IoMethod" in os.h. Use the
existing os_*.c as templates, yes.
If you can provide a largely posix like interface to your file system, you
could use os_unix.c largely unchanged. You might want to strip out the
nightmare locking code, though:)
Another question:
Because my project will run in an embedded environment, so I have to
take care of the RAM consumption. I have went through the mail list, but
not found the description of minimum RAM usage.
Could anyone tell me how much RAM is needed to run SQLite in an embedded
environment?
That depends. SQLite can have functionality conditionally compiled out,
reducing it's size. The front page (http://www.sqlite.org/) proclaims:
"Small code footprint: less than 250KiB fully configured or less than
150KiB with optional features omitted."
YMMV. Your best bet is to choose the features you don't need, compile up
your target library, and measure the code size yourself.
Thanks in advance!
Best regards,
Sarah
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
