diff options
author | Jens Wiklander <jens.wiklander@linaro.org> | 2017-03-15 18:24:30 +0100 |
---|---|---|
committer | Jens Wiklander <jens.wiklander@linaro.org> | 2017-03-17 15:10:18 +0100 |
commit | 879237aee0d08dee2c636e1fadefc842ccf5905e (patch) | |
tree | 43d802aba21ae139ed8539e0db4b98f16ba11d56 /documentation | |
parent | df05d4ea7d586234a254d60818154256cac10489 (diff) |
core: FS: remove fop->seek()
Simplifies file operations interface and implementation by removing the
file operation function pointer seek(). read() and write() takes and
additional position argument to avoid keeping track of the position in
the FS layer. The file position was already maintained in parallel in
struct tee_obj.
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>
Acked-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/secure_storage_sql.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/documentation/secure_storage_sql.md b/documentation/secure_storage_sql.md index 14aa9f33..620e4777 100644 --- a/documentation/secure_storage_sql.md +++ b/documentation/secure_storage_sql.md @@ -46,8 +46,8 @@ the SQL filesystem is the **tee_file_operations** structure `sql_fs_ops`. The secure side of the SQL FS implementation is mostly in [core/tee/tee_sql_fs.c](../core/tee/tee_sql_fs.c). This file maps the -operations in `sql_fs_ops` such as `open`, `truncate`, `read`, `write`, -`seek` and so on, to similar operations on a file that is a container for +operations in `sql_fs_ops` such as `open`, `truncate`, `read`, `write` +and so on, to similar operations on a file that is a container for the encrypted data and associated meta-data. This container is created and manipulated by `tee-supplicant` on request from the secure OS. Its logical layout is similar to REE FS except that there's only a single version of @@ -56,7 +56,7 @@ each field as atomic updates are ensured by **libsqlfs** instead. How this file is stored in the SQLite database is private to **libsqlfs**. From the point of view of OP-TEE, it is a byte-addressable linear file on which atomic updates can be performed through a standard interface (`open`, -`truncate`, `seek`, `read`, `write`...) with the addition of `begin_transaction` +`truncate`, `read`, `write`...) with the addition of `begin_transaction` and `end_transaction`. ## Encryption |