Skip to content

K
Kernel Liteos A

m0_37767187 / Kernel Liteos A
与 Fork 源项目一致

Fork自 OpenHarmony / Kernel Liteos A

通知 1
Star 0
Fork 0
K
Kernel Liteos A

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 19 3月, 2022 2 次提交
    • Z
      fix: 修复內源检视问题 · f7a86305
      由 zhushengle 提交于 
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I3e4e26d55dedc1eb079911eaee59a8bddf4e8eee
      f7a86305
    • Z
      feat: swtmr机制与调度分离，调度只针对通用线程，不针对特殊功能 · 6d8cef40
      由 zhushengle 提交于 
      背景：
原调度机制与软件定时器实现混合，调度时间链表存在两个链表，
任务切换时需要遍历两个链表才可以获取到最终的tick响应时间。
软件定时作为一个独立的功能，不应该和调度强耦合，而且软件定时
器作为一个任务，某个软件定时器的响应时间应该是软件定时器任务的
响应时间，不应该直接做为tick中断的响应时间。

方案描述：
1.将软件定时器从调度分离，作为一个独立的机制，从调度角度看其就是一个任务
2.软件定时器从调度分离之后，其timelist遍历从tick中断移动至软件定时器任务中
3.优化软件定时器的均衡调度

优势：
1.将软件定时器与调度完全分离，使得调度功能单一化，便于后续其它调度算法的引入
2.优化tick中断，减小tick中断耗时
3.优化通过写队列唤醒软件定时器任务去执行软件定时器钩子为插队列，减少软件定时
器机制本身的耗时，提升软件定时器的实时性
4.优化软件定时器均衡调度，使得软件定时器均匀分布于多核，提升软件定时器的实时性
Signed-off-by: Nzhushengle <zhushengle@huawei.com>
Change-Id: I07c01f134e69c1d9b7061ddf5a231df1ee99b68e
      6d8cef40
  3. 18 3月, 2022 1 次提交
  5. 14 3月, 2022 2 次提交
  7. 10 3月, 2022 1 次提交
  9. 09 3月, 2022 1 次提交
    • Y
      fix: 修复3.1源码检视的问题 · 9a030d69
      由 yinjiaming 提交于 
      【背景】
3.1 代码检视过程中有一些问题需要修复

【修改方案】
修改了失效的文档链接,更改了一些非可执行文件的权限

【影响】
对现有的产品编译不会有影响。
Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
Change-Id: If87ac9a3e17ba679f4712552f5a89cc13349287e
      9a030d69
  11. 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
  13. 03 3月, 2022 1 次提交
    • Y
      fix: 主干告警清理 · 672bc729
      由 yinjiaming 提交于 
      【背景】
主干告警清理

【修改方案】
在需要的地方添加了强制类型转换

【影响】
对现有的产品编译不会有影响。
Signed-off-by: Nyinjiaming <yinjiaming@huawei.com>
Change-Id: Id6693137310d8c2e63f4e5489564d7c01c016a18
      672bc729
  15. 27 1月, 2022 1 次提交
  17. 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
  19. 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
  21. 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
  23. 07 1月, 2022 2 次提交
  25. 17 12月, 2021 1 次提交
  27. 30 11月, 2021 1 次提交
  29. 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
  31. 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
  33. 16 11月, 2021 1 次提交
  35. 15 11月, 2021 1 次提交
    • L
      fix: A核代码静态告警定期清理 · 9ba725c3
      由 lnlan 提交于 
      【背景】A核代码静态告警定期清理

【修改方案】
1，根据codex等工具分析结果，进行必要的规范等问题修改

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

re #I4I0O8
Signed-off-by: Nwangchen <253227059@qq.com>
      9ba725c3
  37. 10 11月, 2021 1 次提交
  39. 06 11月, 2021 1 次提交
  41. 04 11月, 2021 1 次提交
  43. 02 11月, 2021 2 次提交
  45. 29 10月, 2021 1 次提交
  47. 28 10月, 2021 1 次提交
  49. 22 10月, 2021 1 次提交
  51. 14 10月, 2021 1 次提交
  53. 11 10月, 2021 1 次提交
  55. 30 9月, 2021 2 次提交
  57. 28 9月, 2021 1 次提交
    • L
      feat: L0-L1 支持Perf · 6e0a3f10
      由 LiteOS2021 提交于 
          1.【需求描述】：
         L0-L1 支持Perf，提供2种模式的配置， 及3大类型的事件配置：
         2种模式：计数模式（仅统计事件发生次数）、采样模式（收集上下文如任务ID、pc、backtrace等）。
         3种事件类型：CPU硬件事件（cycle、branch、icache、dcache等）、OS软件事件（task switch、mux pend、irq等）、高精度周期事件（cpu          clock）。
    2.【方案描述】：
         L0:
         基于事件采样原理，以性能事件为基础，当事件发生时，相应的事件计数器溢出发生中断，在中断处理函数中记录事件信息，包括当前的pc、当前运         行的任务ID以及调用栈等信息。
         L1:
         新增perf字符设备，位于“dev/perf”，通过对设备节点的read\ioctl,实现用户态perf

    BREAKING CHANGE:
    1.新增一系列perf的对外API，位于los_perf.h中.
    LOS_PerfInit配置采样数据缓冲区
    LOS_PerfStart开启Perf采样
    LOS_PerfStop停止Perf采样
    LOS_PerfConfig配置Perf采样事件
    LOS_PerfDataRead读取采样数据
    LOS_PerfNotifyHookReg 注册采样数据缓冲区的钩子函数
    LOS_PerfFlushHookReg 注册缓冲区刷cache的钩子

    2. 用户态新增perf命令
  【Usage】:
./perf [start] /[start id] Start perf.
./perf [stop] Stop perf.
./perf [read nBytes] Read nBytes raw data from perf buffer and print out.
./perf [list] List events to be used in -e.
./perf [stat] or [record] <option> <command>
         -e, event selector. use './perf list' to list available events.
         -p, event period.
         -o, perf data output filename.
         -t, taskId filter(whiltelist), if not set perf will sample all tasks.
         -s, type of data to sample defined in PerfSampleType los_perf.h.
         -P, processId filter(whiltelist), if not set perf will sample all processes.
         -d, whether to prescaler (once every 64 counts), which only take effect on cpu cycle hardware event.

    Close #I47I9A
Signed-off-by: NLiteOS2021 <dinglu@huawei.com>
Change-Id: Ieb9b7483c85d1495df7c55bc0027f4309dff9814
      6e0a3f10
  59. 27 9月, 2021 1 次提交
  61. 18 9月, 2021 1 次提交
  63. 14 9月, 2021 1 次提交
  65. 13 9月, 2021 1 次提交
  67. 08 9月, 2021 1 次提交
    • A
      refactor: 内核目录结构整理 · 33d0c1bd
      由 arvinzzz 提交于 
      1. 原kernel/common目录下属于内核拓展组件，统一移入kernel/extend管理
2. Kconfig分层，各模块自己的配置放到自己目录下管理
3. 原platform下不属于平台的公共代码抽到kernel/common下，只留板级链接脚本和一些编译脚本指向device目录下触发平台相关的编译
4. 对外公共头文件统一抽到对外include路径
5. 废弃宏，头文件清理

close: #I48KI4
Signed-off-by: Narvinzzz <zhaotianyu9@huawei.com>
Change-Id: I0cf5ea81c92a8fa7b113da9cbdc8b7bc935f5aae
      33d0c1bd
  69. 07 9月, 2021 1 次提交
    • G
      fix: dyload open close failed · 5e87d8c1
      由 Guangyao Ma 提交于 
      本次提交修复内核加载器，异常情况分支的一个bug：mksh通过exec命令（mksh内置命令
，正常情况下，该命令成功执行会复用mksh进程空间，拉起新的指定进程）。但是如果
进程没有成功加载的情况下，内核加载器的异常分支会错误释放mksh的fd句柄。最终导致
下次拉起其他进程时（fork + exec方式），新的进程会继承fd，映射了早就释放的sysfd
，此时的sysfd可能已经被复用，issue场景下这个sysfd被加载过程中打开的libc.so占用
，exec时会释放procfd->sysfd(错误的映射关系)，最终新进程libc.so被关闭。
导致内核崩溃。

close #I452Z7
Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
Change-Id: Ifca809f88b5ffcfb879dc5520d1f6adf5cf92bcd
      5e87d8c1