Skip to content

K
Kernel Liteos A

OpenHarmony / Kernel Liteos A
1 年多 前同步成功

通知 460
Star 414
Fork 55
K
Kernel Liteos A
切换分支/标签
  1. 21 7月, 2022 1 次提交
    • Y
      fix: 拼写错误修正 · 99ea8d4e
      由 yinjiaming 提交于 
      【背景】
代码中存在拼写错误

【修改方案】
修改存在拼写错误的地方

【影响】
对现有的产品编译不会有影响。

re #I5IA7P
Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
Change-Id: Idd5d7fc9705e5ec661596aa6533402e8d4a8a117
      99ea8d4e
  3. 23 6月, 2022 1 次提交
  5. 30 3月, 2022 1 次提交
  7. 24 3月, 2022 1 次提交
  9. 22 3月, 2022 1 次提交
  11. 14 3月, 2022 1 次提交
  13. 27 1月, 2022 1 次提交
  15. 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
  17. 25 12月, 2021 1 次提交
  19. 10 11月, 2021 1 次提交
  21. 02 11月, 2021 1 次提交
    • L
      修复ppoll接口"[ERR]OsMemFree check error!"报错 · 2e3bbf1e
      由 lnlan 提交于 
      【背景】
1.内核中释放用户空间指针报错:"[ERR]OsMemFree check error!"
2.现有ppoll实现存在问题
3.相关用例需要整理
【修改方案】
1.去掉释放用户空间指针操作
2.更正逻辑错误
3.更正掩码设置与恢复不起作用
4.修复补充现有用例
【影响】
对现有的产品编译不会有影响。

re #I47YWZ

Change-Id: Ib2f60986e9cafb2ea5ef1097ab8552cbb1ede5b4
Signed-off-by: Nlnlan <lanleinan@163.com>
      2e3bbf1e
  23. 29 10月, 2021 2 次提交
  25. 28 10月, 2021 1 次提交
    • T
      fix: fix ppoll · a55f68f9
      由 teamol 提交于 
      1.modifications:
modified:   syscall/fs_syscall.c
2.modify 2 testcases:
IO/full/IO_test_ppoll_001.cpp
IO/full/IO_test_ppoll_002.cpp
3.influence:
none
Signed-off-by: 悟空又丢了's avatarpef <cyd1997@126.com>
Change-Id: I85fc091098a6dfef1a4694a3bbc489640ee6dda2
      a55f68f9
  27. 11 10月, 2021 1 次提交
    • L
      fix: 修复PR520缺陷 · 40338918
      由 lnlan 提交于 
      【背景】
https://gitee.com/openharmony/kernel_liteos_a/pulls/520
上面修改，信号处理时才会释放申请的内存，当信号被屏蔽，且一直发送该信号时，
内存占用会不断变大
【修改方案】
1.
信号发送时已经有该信号的siginfo在链表中时，不再重新申请，重复使用之前的siginfo.

【影响】
对现有的产品编译不会有影响。

re#I4DEG5
Signed-off-by: Nlanleinan <lanleinan@163.com>

Change-Id: I74b3b7ff0b9efb0179313af9a0c8d1e12d1db5bb
      40338918
  29. 10 10月, 2021 1 次提交
  31. 10 9月, 2021 1 次提交
    • L
      fix: 修复sigwait等待到的信号值与获取的siginfo中的值不一致 · c3facd1b
      由 lnlan 提交于 
      【背景】
集成测试发送两个不同的信号，sigwait第二次等到的仍是第一个信号
经定位，信号在kill时会将相关的siginfo信息拷贝到taskcb的unbinfo中，sigwait
处理时从unbinfo拷贝给用户。若此信号发送时处于屏蔽状态，再有其他信号发送会覆盖
掉unbinfo，此时sigwait等待这个信号获取到的info已经被覆盖
【修改方案】
1. 每个任务添加一个siginfo缓存链表，在处理信号前夕从缓存链表取出info到unbinfo中

【影响】
对现有的产品编译不会有影响。

re #I3M12H
Signed-off-by: Nlanleinan <lanleinan@163.com>

Change-Id: If4b064c18773f8eca7419c665977260167b09810
      c3facd1b
  33. 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
  35. 26 8月, 2021 1 次提交
    • G
      fix: solve SIGCHLD ignored in sigsuspend() · 5a80d4e1
      由 Guangyao Ma 提交于 
      在如下场景signal可能得不到及时处理：
1、进程A设置信号a阻塞
2、进程A收到信号a
3、进程A调用sigsuspend结束阻塞
原则上，步骤三应该立刻处理之前被阻塞的信号a，调用信号处理函数，并且sigsuspend
返回。现在的问题是，信号a没有得到及时处理，并且进程A阻塞在sigsuspend()调用流程
。
本次修改，在1、2、3场景下，sigsuspend()处理过程中，如果发现已经收到信号，待处理
时，会立刻进行调度切换，再次调度回来时，在调度模块中，会先主动处理已经收到的信
号，最后sigsuspend返回用户态。

close #I47CKK
Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
Change-Id: I1b30a938a2d18c3f58989d40eee0503ceffb27b5
      5a80d4e1
  37. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      由 wjj 提交于 
      killpg：给进程组发信号
waitid：等待进程结束
修改测试用例到full里面

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

Close #I3S0N0

Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  55. 20 5月, 2021 1 次提交
  57. 19 5月, 2021 3 次提交
  59. 11 5月, 2021 2 次提交
  61. 26 4月, 2021 1 次提交
  63. 25 4月, 2021 1 次提交
  65. 19 4月, 2021 1 次提交
  67. 02 4月, 2021 1 次提交
    • X
      signal · a041342a
      由 x_xiny 提交于 
      Change-Id: Ia42e914b7a19b7d519010e371f808baa1c6588c0
      a041342a
  69. 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
  71. 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