Go to file
zhushengle cf89f016e9 fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放.
背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
      如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
      号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
      果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
      了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
      那么它持有的内核资源就无法被释放了。
方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
      处理信号,等系统调用结束或缺页异常结束时再去处理信号。
解决的问题:
  1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
  2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
  3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程

Close #I3S0N0

Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
2021-05-24 14:29:37 +08:00
.gitee add issue and pr template 2021-04-07 14:49:32 +08:00
apps !251 fix: clang10 lld could not recognized Oz 2021-05-19 11:14:19 +08:00
arch fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. 2021-05-24 14:29:37 +08:00
bsd remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00
compat/posix refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
drivers/char refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
figures update openharmony 1.0.1 2021-03-11 18:43:57 +08:00
fs refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
kernel fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. 2021-05-24 14:29:37 +08:00
lib remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00
net remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00
platform refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
security remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00
shell refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
syscall fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. 2021-05-24 14:29:37 +08:00
testsuites update testsuites/unittest/process/mutex/process_mutex_test.cpp. 2021-05-20 18:54:14 +08:00
tools refactor: Refactored the kernel boot process and added a init framework 2021-05-20 16:45:43 +08:00
.gitignore fix: Show conflicting files for git apply or patch -p command 2021-04-22 16:44:46 +08:00
BUILD.gn testsuites fixed 2021-04-30 15:07:26 +08:00
Kconfig fix: Remove redundant invalid codes 2021-05-17 14:34:09 +08:00
LICENSE update openharmony 1.0.1 2021-03-11 18:43:57 +08:00
Makefile use -include option instead of including menuconfig manually 2021-04-14 17:56:48 +08:00
README.md TicketNo:DTS2021012805GXU8P0H00 2021-03-16 16:54:09 +08:00
README_zh-HK.md add README_zh-HK.md. 2021-03-29 12:01:23 +08:00
README_zh.md TicketNo:DTS2021012805GXU8P0H00 2021-03-16 16:54:09 +08:00
build.sh [Desc]Modify the vendor configuration file path because the product_path 2021-03-23 22:23:19 +08:00
config.mk remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00
kernel_test.sources remove __cplusplus guards in .c files 2021-04-19 18:28:25 +08:00

README.md

LiteOS Cortex-A

Introduction

The OpenHarmony LiteOS Cortex-A is a new-generation kernel developed based on the Huawei LiteOS kernel. Huawei LiteOS is a lightweight operating system OS built for the Internet of Things IoT field. With the rapid development of the IoT industry, OpenHarmony LiteOS Cortex-A brings small-sized, low-power, and high-performance experience and builds a unified and open ecosystem for developers. In addition, it provides rich kernel mechanisms, more comprehensive Portable Operating System Interface POSIX, and a unified driver framework, Hardware Driver Foundation HDF, which offers unified access for device developers and friendly development experience for application developers. Figure 1 shows the architecture of the OpenHarmony LiteOS Cortex-A kernel.

Figure 1 Architecture of the OpenHarmony LiteOS Cortex-A kernel

Directory Structure

/kernel/liteos_a
├── apps                   # User-space init and shell application programs
├── arch                   # System architecture, such as ARM
│   └── arm                # Code for ARM architecture
├── bsd                    # Code of the driver and adaptation layer module related to the FreeBSD, such as the USB module
├── compat                 # Kernel API compatibility
│   └── posix              # POSIX APIs
├── drivers                # Kernel drivers
│   └── char               # Character device
│       ├── mem            # Driver for accessing physical input/output (I/O) devices
│       ├── quickstart     # APIs for quick start of the system
│       ├── random         # Driver for random number generators
│       └── video          # Framework of the framebuffer driver
├── fs                     # File system module, which mainly derives from the NuttX open-source project
│   ├── fat                # FAT file system
│   ├── jffs2              # JFFS2 file system
│   ├── include            # Header files exposed externally
│   ├── nfs                # NFS file system
│   ├── proc               # proc file system
│   ├── ramfs              # RAMFS file system
│   └── vfs                # VFS layer
├── kernel                 # Kernel modules including the process, memory, and IPC modules
│   ├── base               # Basic kernel modules including the scheduling and memory modules
│   ├── common             # Common components used by the kernel
│   ├── extended           # Extended kernel modules including the dynamic loading, vDSO, and LiteIPC modules
│   ├── include            # Header files exposed externally
│   └── user               # Init process loading
├── lib                    # Kernel library
├── net                    # Network module, which mainly derives from the lwIP open-source project
├── platform               # Code for supporting different systems on a chip (SOCs), such as Hi3516D V300
│   ├── hw                 # Logic code related to clocks and interrupts
│   ├── include            # Header files exposed externally
│   └── uart               # Logic code related to the serial port
├── platform               # Code for supporting different systems on a chip (SOCs), such as Hi3516D V300
├── security               # Code related to security features, including process permission management and virtual ID mapping management
├── syscall                # System calling
└── tools                  # Building tools as well as related configuration and code

Constraints

  • Programming languages: C and C++
  • Applicable development boards: Hi3518E V300 and Hi3516D V300
  • Hi3518E V300 uses the JFFS2 file system by default, and Hi3516D V300 uses the FAT file system by default.

Usage

OpenHarmony LiteOS Cortex-A supports the Hi3518E V300 and Hi3516D V300. You can develop and run your applications based on both development boards.

Preparations

You need to set up the compilation environment on Linux.

Source Code Acquisition

Download and decompress a set of source code on a Linux server to acquire the source code. For more acquisition methods, see Source Code Acquisition.

Compilation and Building

For details about how to develop the first application, see:

Repositories Involved

Kernel subsystem

drivers_liteos

kernel_liteos_a