[:NitinGupta:Nitin Gupta]

[[MailTo(nitingupta910 AT gmail DOT com)]]

----
= Manages storage for variable sized data objects =
=== It is designed especially for embedded devices. ===
----
[[BR]]
This page describes the problem it tries to solve and its design details.
[[BR]]
[[BR]]
'''Problem Statement[[BR]]'''
Normally when you allocate arbitrary sized objects using kmalloc()/vmalloc() there is big space wastage due to internal fragmentation. So, if memory is at premium, tight storage is required for these variables sized data items which is what VStore does. This however comes at cost of some speed.
[[BR]][[BR]]
'''How to use it?'''[[BR]]
To store data:
{{{
vstore_write(objectID /* out */, data_to_store, len)
}}}

To restore this data:
{{{
vstore_read(objectID, buffer, len /* out */)
}}}

'''NOTE:''' In vstore_read(), make sure that buffer is big enough to store data assoc. with object 'ObjectID' - the 'len' (out) param will tell how much data was read into the buffer. Thus, to make sure that buffer size is always sufficient, either you ''know'' maximum size for objects stored (more common case) or you will have to track size of each object stored to provide buffer of right size.
[[BR]][[BR]]
== Design Details ==
----
'''Design Goals:'''
 * Minimize fragmentation
 * Minimize metadata overhead
 * Fast store and restore
 * Provide dense storage - minimize spreading of chunks associated with any particular data object into multiple pages. This improves locality and hence performance.
 * Portability across different archs
[[BR]]
Each data item stored is split into multiple '''chunks''' (small contiguous physical space) and these chunks can then be spread across multiple physical pages. The Metadata associated with each chunk is stored in the beginning of chunk itself with necessary padding added to maintain alignment constraints.

Some jargon:
{{{

}}}