Skip to content

K
Kernel Liteos A

举世唯美 / Kernel Liteos A
与 Fork 源项目一致

Fork自 OpenHarmony / Kernel Liteos A

通知 1
Star 0
Fork 0
K
Kernel Liteos A

前往新版Gitcode，体验更适合开发者的 AI 搜索 >>

切换分支/标签
  1. 11 2月, 2023 1 次提交
  3. 09 2月, 2023 1 次提交
  5. 03 2月, 2023 1 次提交
  7. 30 1月, 2023 1 次提交
  9. 19 1月, 2023 1 次提交
    • Z
      feat: 支持time容器 · 16ed05e8
      由 zhushengle 提交于 
      BREAKING CHANGE:
支持ipc容器及增强对外变更:
1.clone 支持CLONE_NEWTIME
2.增加”/proc/[pid]/container/time" 用于查询容器信息
3.增加”/proc/[pid]/container/time_for_children" 用于查询容器信息
4.增加”/proc/[pid]/container/pid_for_children" 用于查询容器信息
5.增加”/proc/[pid]/time_offsets" 用于查询和配置time容器信息

Close #I6B0A3
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I54d79937ca608a10a4384f61e11c88757f833edf
      16ed05e8
  11. 18 1月, 2023 1 次提交
    • Z
      feat: 支持IPC容器 · 34814c58
      由 zhushengle 提交于 
      BREAKING CHANGE:
支持ipc容器及增强对外变更:
1.clone 支持CLONE_NEWIPC
2.增加”/proc/[pid]/container/ipc" 用于查询容器信息

Close #I6AVMY
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I6a3c248d2d66a5342994c6e0b0aecddea8e32c72
      34814c58
  13. 16 1月, 2023 1 次提交
  15. 14 1月, 2023 1 次提交
  17. 12 1月, 2023 1 次提交
  19. 11 1月, 2023 1 次提交
    • Z
      feat: 支持pid容器 · 20782299
      由 zhushengle 提交于 
      BREAKING CHANGE:
支持pid容器对外变更描述:
1.支持pid容器，使用clone(CLONE_NEWPID)创建
2.shell命令 task -a 不再显示线程信息，只显示系统所有进程信息
3.task命令新增参数-p, task -p pid 可查看改进程下的所有线程信息
4.使用LOS_TaskCreateOnly创建任务时， TSK_INIT_PARAM_S中的processID由原来的记录进程ID修改为记录进程控制块PCB
Close #I68LVW
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I0895da9099cb285b3195af5e383d0fdeaf5c0087

Change-Id: I46a7642eeee73a4531c241e3ba6290dd302600a7
      20782299
  21. 26 4月, 2022 1 次提交
  23. 30 3月, 2022 1 次提交
  25. 18 3月, 2022 1 次提交
  27. 08 3月, 2022 1 次提交
  29. 27 1月, 2022 1 次提交
  31. 21 1月, 2022 1 次提交
    • Z
      feat: 调度相关模块间依赖优化 · 0e3936c4
      由 zhushengle 提交于 
      背景：
    调度、线程、软件定时器、sortlink、percpu、异常、workqueue模块相互耦合，存在很多不属于本模块的实现，
导致这几个模块间依赖混乱、且到处引用其它模块的内部成员。

方案描述：
    解决上述依赖混乱的问题，为后续调度框架打基础，优化后依赖关系：

                                                              | ---> los_swtmr_pri.h --> workqueue
los_sortlink_pri.h: ---> los_sched_pri.h --> los_task_pri.h -->
   作为基础算法                                               | ---> ipc
(现在为双向链表),
做到功能最小化，
便于后续其它算法替换

调度框架大体方案描述：

1.cpu run queue ----> 任务延时队列

                                         |---- 调度队列
                   |----  EDF        --->
                   |                     |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)
                   |
                   |                     |---- 调度队列
2.task ---> 调度策略----> SCHED_RR   --->
                   |                     |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)
                   |
                   |                     |---- 调度队列
                   |----> SCHED_IDLE --->
                                         |---- 方法(Delay、Suspend、Resume、EntReadyQue、Exit等)

Close #I4RPRW
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: Ia54dc1b8a4801a225a52e40555490c1dce0bd75e
      0e3936c4
  33. 02 11月, 2021 2 次提交
  35. 28 10月, 2021 1 次提交
  37. 22 10月, 2021 1 次提交
  39. 19 10月, 2021 1 次提交
  41. 09 10月, 2021 1 次提交
  43. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      由 wjj 提交于 
      killpg：给进程组发信号
waitid：等待进程结束
修改测试用例到full里面

Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094
  45. 11 8月, 2021 1 次提交
    • G
      feat(vfs): vfs支持FD_CLOEXEC标记 · 27dca4d8
      由 Guangyao Ma 提交于 
      首先，POSIX规范规定文件描述符需要支持close-on-exec属性，修改前的vfs不支持close-on-exec，当exec系列函数执行时，进程所有的文件将会被关闭（0，1，2也重新被打开）。但是，系统有些时候是不能在exec时关闭全部文件的，例如在执行exec之前，就需要重定向进程的某些文件描述符时（使用dup2），就希望该文件不被关闭，继续保持重定向属性，shell执行进程并重定向其标准输出到文件，这是我们经常做的事情。

BREAKING CHANGE:
执行exec类函数后，进程拥有的文件描述符情况发生变化：修改前，默认关闭所有的进程文件描述符，0，1，2重新打开；修改后，除非文件描述符拥有FD_CLOEXEC标记，否则该描述符不会被关闭。

re #I3U81W

Change-Id: I54e841ac88e9835ec23e97de0cbc906c4e11f5a4
Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
      27dca4d8
  47. 21 7月, 2021 1 次提交
  49. 01 7月, 2021 1 次提交
  51. 22 6月, 2021 1 次提交
  53. 16 6月, 2021 1 次提交
  55. 05 6月, 2021 1 次提交
  57. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      由 zhushengle 提交于 
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
      如果有信号处理就切去处理信号，信号处理结束后回来继续按原来流程执行。
问题：当用户态线程在执行系统调用或缺页异常时，运行在内核态，如果此时有信
      号需要处理，且该线程已经持有了部分内核资源(如：锁，内存等), 此时如
      果有中断发生，则在中断结束时，就会去处理该信号，此时用户态线程持有
      了内核未释放的资源跑到了用户态去运行，如果该线程在用户态出现问题,
      那么它持有的内核资源就无法被释放了。
方案：用户态线程在执行系统调用和缺页异常时暂时屏蔽信号，防止此时有中断去
      处理信号，等系统调用结束或缺页异常结束时再去处理信号。
解决的问题：
  1. 执行系统调用或缺页异常时屏蔽信号，防止中断去处理信号
  2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
  3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程

Close #I3S0N0

Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  59. 20 5月, 2021 1 次提交
  61. 11 5月, 2021 1 次提交
  63. 08 5月, 2021 1 次提交
  65. 26 4月, 2021 1 次提交
  67. 19 4月, 2021 1 次提交
  69. 02 4月, 2021 1 次提交
  71. 31 3月, 2021 1 次提交
    • Y
      IssueNo:#I3E0F2 · c959d436
      由 YOUR_NAME 提交于 
      Description:Delete VM to support only kernel mode.
Sig:liteos_a
Feature or Bugfix:Feature
Binary Source:No

Change-Id: Ie1029c8fbc0c1b85c138663933118d2d148b7769
      c959d436
  73. 11 3月, 2021 1 次提交
  75. 26 12月, 2020 1 次提交
  77. 25 12月, 2020 1 次提交