1. 11 2月, 2023 1 次提交
  2. 09 2月, 2023 1 次提交
  3. 30 1月, 2023 1 次提交
  4. 14 1月, 2023 1 次提交
  5. 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
  6. 30 3月, 2022 1 次提交
  7. 27 1月, 2022 1 次提交
  8. 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
  9. 02 11月, 2021 2 次提交
  10. 22 10月, 2021 1 次提交
  11. 30 9月, 2021 1 次提交
  12. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      wjj 提交于
      killpg:给进程组发信号
      waitid:等待进程结束
      修改测试用例到full里面
      
      Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
      Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094
  13. 10 8月, 2021 1 次提交
    • H
      fix: 合并进程栈两个地址连续的region · 42f374dd
      Haryslee 提交于
      背景:进程加载的时候,先预申请一个页用作参数拷贝,另外通过mmap方式申请
      额外的虚拟栈空间,此时便有两个地址连续的区间。
      方案:新增内部接口OsStackAlloc,用于申请一个连续的虚拟地址区间,并对其
      中指定区间做物理内存的映射。
      
      close #I43QYJ
      Signed-off-by: NHaryslee <lihao189@huawei.com>
      Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
      42f374dd
  14. 21 7月, 2021 1 次提交
  15. 16 7月, 2021 1 次提交
  16. 01 7月, 2021 1 次提交
  17. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      zhushengle 提交于
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
            如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
      问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
            号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
            果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
            了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
            那么它持有的内核资源就无法被释放了。
      方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
            处理信号,等系统调用结束或缺页异常结束时再去处理信号。
      解决的问题:
        1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
        2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
        3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程
      
      Close #I3S0N0
      
      Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  18. 08 5月, 2021 1 次提交
  19. 19 4月, 2021 1 次提交
  20. 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
  21. 11 3月, 2021 1 次提交
  22. 05 11月, 2020 1 次提交
  23. 13 10月, 2020 1 次提交
  24. 28 9月, 2020 1 次提交
  25. 08 9月, 2020 1 次提交