1. 18 1月, 2023 1 次提交
    • Z
      feat: 支持IPC容器 · 34814c58
      zhushengle 提交于
      BREAKING CHANGE:
      支持ipc容器及增强对外变更:
      1.clone 支持CLONE_NEWIPC
      2.增加”/proc/[pid]/container/ipc" 用于查询容器信息
      
      Close #I6AVMY
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: I6a3c248d2d66a5342994c6e0b0aecddea8e32c72
      34814c58
  2. 11 1月, 2023 1 次提交
    • Z
      feat: 支持pid容器 · 20782299
      zhushengle 提交于
      BREAKING CHANGE:
      支持pid容器对外变更描述:
      1.支持pid容器,使用clone(CLONE_NEWPID)创建
      2.shell命令 task -a 不再显示线程信息,只显示系统所有进程信息
      3.task命令新增参数-p, task -p pid 可查看改进程下的所有线程信息
      4.使用LOS_TaskCreateOnly创建任务时, TSK_INIT_PARAM_S中的processID由原来的记录进程ID修改为记录进程控制块PCB
      Close #I68LVW
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: I0895da9099cb285b3195af5e383d0fdeaf5c0087
      
      Change-Id: I46a7642eeee73a4531c241e3ba6290dd302600a7
      20782299
  3. 29 4月, 2022 1 次提交
  4. 30 3月, 2022 1 次提交
  5. 26 3月, 2022 1 次提交
  6. 19 3月, 2022 1 次提交
    • 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
  7. 14 3月, 2022 1 次提交
  8. 27 1月, 2022 1 次提交
  9. 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
  10. 18 1月, 2022 1 次提交
  11. 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
  12. 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
  13. 14 8月, 2021 1 次提交
  14. 09 8月, 2021 1 次提交
    • Z
      fix: tick 动态化计算优化,消除中断执行时间对系统总体时间的影响,保证软件定时器的响应精度。 · 8df3e8c9
      zhushengle 提交于
      方案描述:
          1.周期软件定时器超时添加一个startTime字段,用于记录当前软件定时器的开始计时的时间,
          在定时器响应时,开始时间修改为上一次响应的结束时间(消除了中断执行时间对软件定时器
          的影响)。
          2.在执行tick中断的过程当中,持有tick动态计算锁,保证在该过程中不会触发tick周期
          的计算,在tick中断结束时统一计算设置。 --- 提升tick中断的执行效率
          3.在设置tick周期时,减掉tick中断执行的时间,减小周期动态化带来的时间误差
          4.新增LOSCFG_BASE_CORE_TICK_PER_SECOND_MINI配置宏,用于配置tick中断的最小响应精度
      Close #I43UQJ
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: Icd1159a1890046b13602b7a18dcd6234d5c61a89
      8df3e8c9
  15. 06 8月, 2021 1 次提交
  16. 01 7月, 2021 1 次提交
  17. 18 5月, 2021 1 次提交
  18. 19 4月, 2021 1 次提交
  19. 11 3月, 2021 1 次提交
  20. 13 10月, 2020 1 次提交
  21. 08 9月, 2020 1 次提交