1. 09 3月, 2022 1 次提交
    • Y
      fix: 修复3.1源码检视的问题 · 9a030d69
      yinjiaming 提交于
      【背景】
      3.1 代码检视过程中有一些问题需要修复
      
      【修改方案】
      修改了失效的文档链接,更改了一些非可执行文件的权限
      
      【影响】
      对现有的产品编译不会有影响。
      Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
      Change-Id: If87ac9a3e17ba679f4712552f5a89cc13349287e
      9a030d69
  2. 08 3月, 2022 1 次提交
  3. 07 3月, 2022 1 次提交
    • Z
      feat: 优化shell 命令 · f02d40d2
      zhushengle 提交于
        1.优化task 命令关中断时间较长的问题
        2.优化hwi 命令,可以查看不同核的中断分布情况
        3.丰富hiw 命令,统计每个中断在一定时间内的平均执行时间和最大执行时间
        4.丰富swtmr 命令,在debug模式下支持查看各软件定时器的运行情况, 默认关闭
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: I01cfe50c918da51f9de5b460e9eb91a863e1de36
      f02d40d2
  4. 03 3月, 2022 1 次提交
    • Y
      fix: 主干告警清理 · 672bc729
      yinjiaming 提交于
      【背景】
      主干告警清理
      
      【修改方案】
      在需要的地方添加了强制类型转换
      
      【影响】
      对现有的产品编译不会有影响。
      Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
      Change-Id: Id6693137310d8c2e63f4e5489564d7c01c016a18
      672bc729
  5. 27 1月, 2022 1 次提交
  6. 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
  7. 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
  8. 18 1月, 2022 1 次提交
  9. 13 1月, 2022 1 次提交
    • 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
  10. 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
  11. 07 1月, 2022 2 次提交
  12. 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
  13. 22 12月, 2021 1 次提交
  14. 17 12月, 2021 1 次提交
  15. 14 12月, 2021 2 次提交
  16. 11 12月, 2021 1 次提交
  17. 03 12月, 2021 2 次提交
  18. 01 12月, 2021 1 次提交
  19. 30 11月, 2021 1 次提交
  20. 29 11月, 2021 1 次提交
    • Z
      feat: 支持L1 低功耗框架 · 64e49aba
      zhushengle 提交于
      方案描述:
         和L0保持一致,上层通过proc文件系统操作:
         power_mode  支持的低功耗模式,通过对该文件进行write操作可以设置低功耗模式
         power_count powermanager模块通过对该文件操作,和内核进行交互,简要流程如下:
           while (1) {
             open  // 打开该文件
             read  // 使powermanager低功耗任务常阻塞,当系统无任何模块持锁时,会唤醒该任务
             write // 进行低功耗流程
             close // 关闭该文件
           }
         power_lock    write该文件,持锁
         power_unlock  writw该文件,释放锁
      
      Close #I4JSO
      
      Change-Id: I73fcdeeb5e2039484b3351a81b46a0892b349fe9
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      64e49aba
  21. 27 11月, 2021 1 次提交
    • L
      feat: L0~L1 支持Lms · e748fdbe
      LiteOS2021 提交于
      1.【需求描述】:
         支持内核态和用户态堆内存非法访问检测,包括:越界访问、double free、释放后使用;支持libc常用高频函数内存检测;支持安全函数内存检测;读写检测可配可裁剪。
      2.【方案描述】:
         L0 ~ L1:
         (1).影子内存映射与标记
         (2).编译器使能-fsanitize=kernel-address 自动插桩检测点
         (3).实时校验影子内存的合法性;
         (4).错误访问打印回溯栈
      
      BREAKING CHANGE: 新增支持API:
      
      LOS_LmsCheckPoolAdd使能检测指定内存池
      LOS_LmsCheckPoolDel不检测指定内存池
      LOS_LmsAddrProtect为指定内存段上锁,不允许访问
      LOS_LmsAddrDisableProtect去能指定内存段的访问保护
      
      Close #I4HYAV
      Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
      Change-Id: Id8e5c890656da9edc4a22227e6a3c32205c024ce
      e748fdbe
  22. 16 11月, 2021 1 次提交
  23. 15 11月, 2021 1 次提交
    • L
      fix: A核代码静态告警定期清理 · 9ba725c3
      lnlan 提交于
      【背景】A核代码静态告警定期清理
      
      【修改方案】
      1,根据codex等工具分析结果,进行必要的规范等问题修改
      
      【影响】
      对现有的产品编译不会有影响。
      
      re #I4I0O8
      Signed-off-by: Nwangchen <253227059@qq.com>
      9ba725c3
  24. 11 11月, 2021 2 次提交
  25. 10 11月, 2021 2 次提交
  26. 08 11月, 2021 1 次提交
  27. 06 11月, 2021 1 次提交
  28. 04 11月, 2021 2 次提交
  29. 02 11月, 2021 5 次提交
  30. 29 10月, 2021 1 次提交