secGear/0044-Optimize-Engilish-version-readme-file.patch

From e436bc4efa36a1d83e4059d71e85311cada9b528 Mon Sep 17 00:00:00 2001
From: blue <jingood@yeah.net>
Date: Mon, 28 Jun 2021 08:44:03 +0000
Subject: [PATCH] Optimize Engilish version readme file

---
 README.en.md | 43 ++++++++++++++++++++++---------------------
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/README.en.md b/README.en.md
index 8d5f80a..617ccac 100644
--- a/README.en.md
+++ b/README.en.md
@@ -6,9 +6,9 @@ secGear
 Introduction
 -----------
 
-secGear is an SDK to develop confidential computing apps based on hardware enclave features. The target is to use
-single source code for developers to develop apps running on different hardware. Currently secGear supports Intel SGX
-and iTrustee running in ARM Trustzone.
+secGear is an SDK to develop confidential computing apps based on hardware enclave features. The target is to write
+single source code for apps running on different hardware. Currently secGear supports Intel SGX and iTrustee running
+in ARM Trustzone.
 
 Build and Install
 ----------------
@@ -30,13 +30,13 @@ Assuming the development directory is .../secGear/examples/test/
 		};
 	};
 
-include "secgear_urts.h", from "secgear_tstdc.edl" import *, to shield the difference between sgx and iTrustee when
-calling the C library. So as long as you use the c library functions, for the consistency of your development code,
-the two files need be imported.
+include "secgear_urts.h", from "secgear_tstdc.edl" import *, to shield the difference between SGX and iTrustee when
+calling the C library. So as long as the C library functions are used, for the consistency of the source code, the two
+files need be imported.
 
-For details about edl syntax, please refer to the sgx development document Enclave Definition Language Syntax section.
-At present, sgx and iTrustee are compatible with each other in basic types, pointer buffers, and deep copy of
-structures, but currently only sgx supports features like user_check, Granting Access to ECALLs, Using Switchless
+For details about edl syntax, please refer to the SGX development document Enclave Definition Language Syntax section.
+At present, SGX and iTrustee are compatible with each other in basic types, pointer buffers, and deep copy of
+structures, but currently only SGX supports features like user_check, Granting Access to ECALLs, Using Switchless
 Calls and so on.
 
 Then save as test.edl
@@ -64,9 +64,9 @@ Then save as test.edl
 	add_subdirectory(${CURRENT_ROOT_PATH}/enclave)
 	add_subdirectory(${CURRENT_ROOT_PATH}/host)
 
-Set the CODETYPE EDL_FILE and CODETYPE attributes, which will be used when automatically generating code later.
-On ARM platform, the enclave image needs be named with a unique UUID, so it is dynamically uniquely
-generated using the uuidgen command. The defined DPATH macro is used when loading the enclave image.
+Set the CODETYPE EDL_FILE and CODETYPE attributes, which are used when automatically generating code at later phase.
+On ARM platform, the enclave image needs be named with a unique UUID, so it is dynamically uniquely generated using
+the uuidgen command. The defined DPATH macro is used when loading the enclave image.
 
 
 ### 3 Write the non-secure side code and CMakeLists.txt
@@ -104,22 +104,23 @@ generated using the uuidgen command. The defined DPATH macro is used when loadin
 		return res;
 	}
 	
-#include "enclave.h", to import the secGear header file, #include "test_u.h" to import the automatically generated code
+include "enclave.h", to import the secGear header file, include "test_u.h" to import the automatically generated code
 header file. Next, call cc_enclave_create(...) to create the enclave context, and then call the wrapper of the
 interface described in the edl file to enter the enclave to execute confidential code.
 Finally, call cc_enclave_destroy(...) to destroy the enclave context.
 	
-Note that the interface called here has more context and retval parameters than defined in edl file before.
-This is because this function, generated by the automatic code generation tool according to edl, is a wrapper of
-the real enclave code,  and its declaration is in the test_u.h header file. Where the context parameter is the
-cc_enclave_t * context created before, and retval is the return value of the function defined in edl, and the res
-parameter is the return value of the wrapped function. The prefix of test_u.h is consistent with the prefix of test.edl.
+Note that comparing to arguments defined in edl file, the interface called here has two more arguments, context and retval.
+This is because the function, generated by the automatic code generation tool according to edl, is a wrapper ofthe real 
+enclave function, and its declaration is in the test_u.h header file. Where the context parameter is the
+cc_enclave_t * context created before calling the funciton, and retval is the return value of the function defined in edl,
+and the res argument is the return value of the wrapped function. The prefix of test_u.h is consistent with the prefix of
+test.edl.
 
 If the function defined in edl does not return a value, such as "public void get_string([out, size=32]char *buf);",
-the prototype called by the user will be "res = get_string(context, buf);".
+the interface called by the user would be "res = get_string(context, buf);".
 
-According to these rules, you can write code when the wrapper function is not generated by code generation tool and
-place the wrapper function generation in the compilation phase, which simplifies the development and compilation steps.
+According to these rules, code can be written before the wrapper function is generated by code generation tool in the
+compilation phase, which simplifies the development and compilation steps.
 
 #### 3.2 Write the CMakeLists.txt file of the host.
 
-- 
1.8.3.1