!11010 内核指导文档更新

Merge pull request !11010 from 朱佳鑫/updoc

zh-cn/device-dev/kernel/kernel-standard-build.md

@@ -9,7 +9,7 @@
 使用工程的全量编译命令，编译生成uImage内核镜像
 
 
-```
+```bash
 ./build.sh --product-name hispark_taurus_standard              # 编译hispark_taurus_standard镜像
     --build-target build_kernel                    # 编译hispark_taurus_standard的uImage内核镜像
     --gn-args linux_kernel_version=\"linux-5.10\"  # 编译指定内核版本

zh-cn/device-dev/kernel/kernel-standard-overview.md

 # Linux内核概述
 
-标准系统类设备（参考内存≥128MiB），OpenHarmony选择Linux内核作为基础内核，可以对不同资源受限的设备产品配置出适合的OS内核，为上层提供基础的操作系统能力。
+标准系统类设备是面向应用处理器的设备，支持的设备最小内存为128MiB。OpenHarmony选择Linux内核作为基础内核，可以对不同资源受限的设备产品配置出适合的OS内核，为上层提供基础的操作系统能力。
 
 
 ## Linux内核版本
 
-Linux内核版本分为稳定版本以及长期支持LTS(long term support)版本。
+- Linux内核版本分为稳定版本以及长期支持LTS(long term support)版本。
 
-稳定版本大约每三个月发布一个新版本，包含最新硬件支持、性能改进以及bug修复等。其缺点是整体维护生命周期较短，产品软件不能得到长期稳定的支持。
+- 稳定版本大约每三个月发布一个新版本，包含最新硬件支持、性能改进以及bug修复等。其缺点是整体维护生命周期较短，产品软件不能得到长期稳定的支持。
 
 
-LTS为长期支持版本，“长期支持”体现在对该版本内核的长期维护（对bug和安全方面的修复），一般维护周期达到6年之久。相较于维护周期从6个月到2年不等非LTS内核版本，对一款商用产品来说并不能覆盖其产品完整的生命周期，很有可能会使产品暴露于安全漏洞的风险之中。且LTS版本更新不会包含新的特性升级，保证了版本的稳定，这对追求稳定以及安全的商用产品来说LTS版本更为适合。
+- LTS为长期支持版本，“长期支持”体现在对该版本内核的长期维护（对bug和安全方面的修复），一般维护周期达到6年之久。相较于维护周期从6个月到2年不等非LTS内核版本，对一款商用产品来说并不能覆盖其产品完整的生命周期，很有可能会使产品暴露于安全漏洞的风险之中。且LTS版本更新不会包含新的特性升级，保证了版本的稳定，这对追求稳定以及安全的商用产品来说LTS版本更为适合。
 
 
 ## OpenHarmony内核版本选择

zh-cn/device-dev/kernel/kernel-standard-patch.md

 # OpenHarmony开发板Patch使用指导
 
-1. 合入HDF补丁
-   在kernel/linux/build仓中，按照kernel.mk中HDF的补丁合入方法，合入不同内核版本对应的HDF内核补丁：
-   ```
+1. 合入HDF补丁。
+   按照[kernel.mk](https://gitee.com/openharmony/kernel_linux_build/blob/master/kernel.mk)中HDF的补丁合入方法，合入不同内核版本对应的HDF内核补丁：
+   ```makefile
    $(OHOS_BUILD_HOME)/drivers/hdf_core/adapter/khdf/linux/patch_hdf.sh $(OHOS_BUILD_HOME) $(KERNEL_SRC_TMP_PATH) $(KERNEL_PATCH_PATH) $(DEVICE_NAME)
    ```
 
-2. 合入芯片平台驱动补丁
-   以Hi3516DV300为例：
-
-   在kernel/linux/build仓中，按照kernel.mk中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件patch放到对应路径下：
-   ```
+2. 合入芯片平台驱动补丁，以Hi3516DV300为例。
+   按照[kernel.mk](https://gitee.com/openharmony/kernel_linux_build/blob/master/kernel.mk)中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件patch放到对应路径下：
+   ```makefile
    DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
    DEVICE_PATCH_FILE := $(DEVICE_PATCH_DIR)/$(DEVICE_NAME).patch
    ```
 
-3. 修改自己所需要编译的config
-   在kernel/linux/build仓中，按照kernel.mk中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件config放到对应路径下：
-   ```
+3. 修改自己所需要编译的config。
+   按照[kernel.mk](https://gitee.com/openharmony/kernel_linux_build/blob/master/kernel.mk)中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件config放到对应路径下：
+   ```makefile
    KERNEL_CONFIG_PATH := $(OHOS_BUILD_HOME)/kernel/linux/config/${KERNEL_VERSION}
    DEFCONFIG_FILE := $(DEVICE_NAME)_$(BUILD_TYPE)_defconfig
    ```
@@ -25,4 +23,4 @@
    > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **须知：**
    > 由于OpenHarmony工程的编译构建流程中会拷贝kernel/linux/linux-\*.\*的代码环境后进行打补丁动作，在使用OpenHarmony的版本级编译命令前，需要kernel/linux/linux-\*.\*原代码环境。
    > 
-   > 根据不同系统工程，编译完成后会在out目录下的kernel目录中生成对应实际编译的内核，基于此目录的内核，进行对应的config修改，将最后生成的.config文件cp到config仓对应的路径文件里，即可生效。
+   > 根据不同系统工程，编译完成后会在out目录下的kernel目录中生成对应实际编译的内核，基于此目录的内核，进行对应平台的config修改，将最后生成的.config文件cp到config仓对应平台的路径文件里，即可生效。