1. 31 8月, 2021 1 次提交
    • L
      feat: L0-L1 支持Trace · dc9ec685
      LiteOS2021 提交于
              1.【需求描述】
                  L0~L1 支持Trace,提供两种工作模式:在线模式、离线缓存模式, 用于按时间线追踪系统事件,如任务切换、中断、ipc等。
              2.【方案描述】
                  L0:
                  (1).在内核模块预置静态代码桩
                  (2).触发桩后,收集系统上下文信息
                  (3).离线模式则写入内存,用户可通过dump导出;
                  (4).在线模式通过pipeline对接IDE进行可视化解析和展示;
                  L1:
                  新增trace字符设备,位于"/dev/trace",通过对设备节点的read\write\ioctl,实现用户态trace;
      
              BREAKING CHANGE:
              1.新增一系列trace的对外API,位于los_trace.h中.
              LOS_TRACE_EASY简易插桩
              LOS_TRACE标准插桩
              LOS_TraceInit配置Trace缓冲区的地址和大小
              LOS_TraceStart开启事件记录
              LOS_TraceStop停止事件记录
              LOS_TraceRecordDump输出Trace缓冲区数据
              LOS_TraceRecordGet获取Trace缓冲区的首地址
              LOS_TraceReset清除Trace缓冲区中的事件
              LOS_TraceEventMaskSet设置事件掩码,仅记录某些模块的事件
              LOS_TraceHwiFilterHookReg注册过滤特定中断号事件的钩子函数
      
              Close #I46WA0
      Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
      
      Change-Id: I6a8e64794c4852f2c2980993a06180e09ec6ee0d
      dc9ec685
  2. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      wjj 提交于
      killpg:给进程组发信号
      waitid:等待进程结束
      修改测试用例到full里面
      
      Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
      Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094
  3. 10 8月, 2021 1 次提交
  4. 20 7月, 2021 1 次提交
    • Y
      fix: init进程收到子进程退出信号后,调用fork重新拉起进程,会导致系统卡死 · 35a2f3af
      YOUR_NAME 提交于
      问题原因:init进程执行信号时,线程栈底预留了部分空间给信号上下文使用,
      从而导致处理信号时线程栈底比线程控制块里面记录的大,这样在fork的过程中内核
      从init线程栈底copy线程上下文给新进程时,copy的不是实际运行的栈底,以致于
      新进程的线程上下文不对,在实际运行时跑飞,引发系统卡死。
      解决方案:在fork过程copy线程上下文时,判断是否预留了信号上下文空间,如果预留
      了,则copy的栈底要基于预留后的栈底去copy线程上下文。
      
      close: #I41HOY
      Signed-off-by: Nzff <zhangfanfan2@huawei.com>
      Change-Id: I61cb05183c78919730e3a68c1c85b72fa1decd16
      35a2f3af
  5. 14 7月, 2021 1 次提交
  6. 08 7月, 2021 1 次提交
    • X
      fix:消除编译告警 · e4ff0458
      x_xiny 提交于
      【背景】
       消除编译告警
      
      【修改方案】
       消除编译告警
      
       re #I3ZC1R
      
       Change-Id: I594d0f57e4cbbdb246a6bef1c978a38228123a34
      Signed-off-by: Nx-xiny <1301913191@qq.com>
      
      Change-Id: I1d75cdcdcf9d06ec28e541cdfea77300da7c6bb1
      e4ff0458
  7. 07 7月, 2021 1 次提交
  8. 01 7月, 2021 1 次提交
  9. 16 6月, 2021 1 次提交
  10. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      zhushengle 提交于
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
            如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
      问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
            号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
            果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
            了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
            那么它持有的内核资源就无法被释放了。
      方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
            处理信号,等系统调用结束或缺页异常结束时再去处理信号。
      解决的问题:
        1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
        2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
        3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程
      
      Close #I3S0N0
      
      Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  11. 20 5月, 2021 1 次提交
  12. 19 5月, 2021 3 次提交
  13. 11 5月, 2021 2 次提交
  14. 26 4月, 2021 1 次提交
  15. 25 4月, 2021 1 次提交
  16. 19 4月, 2021 1 次提交
  17. 02 4月, 2021 1 次提交
    • X
      signal · a041342a
      x_xiny 提交于
      Change-Id: Ia42e914b7a19b7d519010e371f808baa1c6588c0
      a041342a
  18. 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
  19. 19 3月, 2021 1 次提交
    • W
      Description:vfs refactoring · d9707508
      wangchenyang 提交于
      Feature or Bugfix:Feature
      Binary Source:Huawei
      PrivateCode(Yes/No):Yes
      
      Change-Id: I175d2648bc6f9078c34de2c0a5c93fda10b86c47
      ChangeID:13306388
      d9707508
  20. 11 3月, 2021 1 次提交
  21. 15 1月, 2021 1 次提交
  22. 08 12月, 2020 1 次提交
  23. 05 12月, 2020 1 次提交
  24. 13 10月, 2020 1 次提交
  25. 28 9月, 2020 2 次提交
  26. 08 9月, 2020 1 次提交