1. 09 4月, 2023 1 次提交
    • Z
      feat: support EDF · 13f68dcf
      zhangdengyu 提交于
      方案描述:
      1、liteos_a调度框架支持EDF调度算法,默认优先调度EDF策略的任务
      2、用户态musl_c库适配新增调度算法,同步修改相关接口以支持用户态创建EDF进程与线程
      
      BREAKING CHANGE:
      support EDF对外变更描述:
      以下接口支持SCHED_DEADLINE调度策略:
      pthread_attr_getschedparam
      pthread_attr_setschedparam
      pthread_getschedparam
      pthread_setschedparam
      pthread_create
      sched_getscheduler
      sched_getparam
      sched_setparam
      sched_setscheduler
      
      Close:#I6T3P3
      Signed-off-by: Nzhangdengyu <zhangdengyu2@huawei.com>
      Change-Id: Ic9fe6896fcae42ae4ee7fe5dfb8e858a6ed19740
      13f68dcf
  2. 03 4月, 2023 1 次提交
  3. 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
  4. 29 4月, 2022 1 次提交
  5. 30 3月, 2022 1 次提交
  6. 24 3月, 2022 1 次提交
  7. 21 3月, 2022 1 次提交
  8. 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
  9. 16 3月, 2022 2 次提交
  10. 14 3月, 2022 1 次提交
  11. 27 1月, 2022 1 次提交
  12. 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
  13. 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
  14. 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
  15. 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
  16. 10 11月, 2021 1 次提交
  17. 02 11月, 2021 1 次提交
  18. 19 10月, 2021 1 次提交
  19. 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
  20. 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
  21. 30 7月, 2021 1 次提交
  22. 21 7月, 2021 1 次提交
  23. 07 7月, 2021 1 次提交
  24. 01 7月, 2021 1 次提交
  25. 10 6月, 2021 1 次提交
  26. 04 6月, 2021 1 次提交
    • Yansira's avatar
      feat: timer_create支持以SIGEV_THREAD方式创建定时器 · e5f6bf05
      Yansira 提交于
      【背景】当前timer_create接口不支持以SIGEV_THREAD的方式创建多个定时器
      
      【修改方案】
      1、内核timer_create接口在创建software timers相应的线程时,使用线程
      taskCB所携带的信息识别各个线程的信号并依据该信息分别派发出信号。
      2、关于用户任务操作许可验证的修改,现在允许同一用户线程向其自身派发信
      号,软件定时器计时结束,向用户态发送相应的信号,完成用户态线程的回调。
      
      【影响】
      对现有的产品暂无影响。
      
      re #I3SRFI
      Signed-off-by: Yansira's avataryansira <yansira@hotmail.com>
      Change-Id: Ia23f5ef01975bf867dd7f5db797a30c264c50501
      e5f6bf05
  27. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      zhushengle 提交于
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
            如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
      问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
            号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
            果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
            了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
            那么它持有的内核资源就无法被释放了。
      方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
            处理信号,等系统调用结束或缺页异常结束时再去处理信号。
      解决的问题:
        1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
        2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
        3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程
      
      Close #I3S0N0
      
      Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  28. 20 5月, 2021 1 次提交
  29. 18 5月, 2021 1 次提交
  30. 08 5月, 2021 1 次提交
  31. 26 4月, 2021 1 次提交
  32. 19 4月, 2021 2 次提交
  33. 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
  34. 24 3月, 2021 1 次提交
    • 星e雨's avatar
      IssueNo:#I29BRN · 9601ecc1
      星e雨 提交于
      Description:Change the exception error message to Panic to clarify what normal does not return.
      Sig:kernel
      Feature or Bugfix:Bugfix
      Binary Source:No
      
      Change-Id: Ie7087cafe709f79604831f6d3eefcee6fe48ccbb
      9601ecc1
  35. 11 3月, 2021 1 次提交
  36. 13 1月, 2021 1 次提交
  37. 26 12月, 2020 1 次提交
  38. 24 12月, 2020 1 次提交