Skip to content

K
Kernel Liteos A

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

通知 460
Star 414
Fork 55
K
Kernel Liteos A
切换分支/标签
  1. 27 1月, 2022 2 次提交
  3. 24 1月, 2022 2 次提交
  5. 22 1月, 2022 4 次提交
  7. 21 1月, 2022 4 次提交
    • Y
      fix: 实现了musl库net模块中的一些函数接口和相应的测试用例 · 3d00a7d2
      由 yinjiaming 提交于 
      【背景】
musl库中关于net模块有一些API需要实现，相应的测试用例设计得不是非常合理.

【修改方案】
删去了与实现的API不相关的测试用例,修改了测试用例中一些错误的地方，
修改了测试用例中依赖硬件环境的一些地方。

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

re #I4JQI1
Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
Change-Id: If57f50b025c84aa79107691efb091dde8e7b2156
      3d00a7d2
    • H
      fix: pr模板补充说明 · e3cd485d
      由 Haryslee 提交于 
      Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: If717ba28495cd657fee965f9464d7165aa0e4168
      e3cd485d
    • 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
    • O
      !784 fix: 针对pr是否同步至release分支，增加原因说明规则 · 95248d44
      由 openharmony_ci 提交于 
      Merge pull request !784 from Harylee/mmu
      95248d44
  9. 20 1月, 2022 1 次提交
    • H
      chore: kernel部件化 · 1ecda9c0
      由 Hongjin Li 提交于 
      1、添加HPM包描述文件bundle.json
2、依赖的三方开源软件，由直接引用路径，改为import对应的gni文件，引用变量
Signed-off-by: NHongjin Li <lihongjin1@huawei.com>
Change-Id: Ice783c19a477626d422a37faf3d420c4965f8ea6
      1ecda9c0
  11. 19 1月, 2022 3 次提交
  13. 18 1月, 2022 4 次提交
  15. 14 1月, 2022 1 次提交
    • O
      !780... · b7d62420
      由 openharmony_ci 提交于 
      !780 L1-liteos-tdd测试liteos_a_process_unittest.bin,liteos_a_security_vid_unittest.bin和liteos_a_time_clock_unittest.bin模块用例un
Merge pull request !780 from xuxinyu/master
      b7d62420
  17. 13 1月, 2022 2 次提交
    • X
      fix:... · 87b8e6b0
      由 x_xiny 提交于 
       fix: L1-liteos-tdd测试liteos_a_process_unittest.bin,liteos_a_security_vid_unittest.bin和liteos_a_time_clock_unittest.bin模块用例un

【背景】L1-liteos-tdd测试liteos_a_process_unittest.bin,liteos_a_security_vid_unittest.bin和liteos_a_time_clock_unittest.bin模块用例un

【修改方案】
 1.暂时将musl中的exit()接口中的原子操作改为使用mutex方式实现
 2.删除内核中不必要的打印

re #I4K9A5
Signed-off-by: Nxuiny <xuxinyu6@huawei.com>
Change-Id: Ifdbb9154c7541b863670bb4e3bcde2587970df38
      87b8e6b0
    • O
      !765 处理A核编译告警 · 321018ce
      由 openharmony_ci 提交于 
      Merge pull request !765 from yinjiaming/yjm-kernel-20220105
      321018ce
  19. 12 1月, 2022 1 次提交
  21. 11 1月, 2022 2 次提交
  23. 10 1月, 2022 2 次提交
  25. 08 1月, 2022 1 次提交
    • H
      fix: MMU竞态问题修复 · 748e0d8f
      由 Haryslee 提交于 
      背景：同一个进程的多个线程读写同一个PTE时，由于PTE无保护，存在竞态问题。
方案：新增spinlock保护PTE，包括大锁跟小锁。大锁：一个进程只有一个spinlock锁，多个线程
读写PTE时竞争一把锁，锁的内存占用小，但系统性能降低；小锁：每个页表持有一把spinlock，
由于锁是page结构体的一个字段，内存消耗较大，但是相对大锁性能较优。系统默认使用大锁,用
户可根据具体需要配置使用大锁还是小锁。

close #I2WARC
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: I5612eeac1f65507160035eae16af61f285182eda
      748e0d8f
  27. 07 1月, 2022 5 次提交
  29. 05 1月, 2022 1 次提交
  31. 30 12月, 2021 1 次提交
  33. 29 12月, 2021 1 次提交
    • H
      fix: 修复重复执行内存用例导致系统卡死问题 · 6c2b163c
      由 Haryslee 提交于 
      背景：重复执行内存测试用例约几百次，系统大概率出现卡死现象，经分析知，系统卡在
内存spinlock锁中，CPU1在获取内存spinlock锁后打印异常信息，此时循环buffer满了，
CPU0此时进入异常且尝试拿取内存spinlock锁，两个核都处于锁中断锁任务状态，CPU1
写事件触发调度打印输出失败，进而在write接口中死循环无法退出，导致两个核都卡住。
方案：在write接口中增加一个判断条件：当前核处于锁任务状态且循环buffer满了时候，
直接退出循环，丢弃打印信息（持有spinlock锁后一般禁止输出打印信息）。

close #I4F7PO
Signed-off-by: NHaryslee <lihao189@huawei.com>
Change-Id: I3f49a1bb211821e9c5d1d220d6867962d6a45a79
      6c2b163c
  35. 25 12月, 2021 1 次提交
  37. 24 12月, 2021 2 次提交