1. 02 11月, 2021 1 次提交
  2. 29 10月, 2021 1 次提交
  3. 28 10月, 2021 1 次提交
  4. 22 10月, 2021 2 次提交
  5. 19 10月, 2021 1 次提交
  6. 14 10月, 2021 2 次提交
  7. 12 10月, 2021 1 次提交
  8. 11 10月, 2021 2 次提交
  9. 10 10月, 2021 1 次提交
  10. 09 10月, 2021 1 次提交
  11. 08 10月, 2021 1 次提交
  12. 30 9月, 2021 2 次提交
  13. 29 9月, 2021 1 次提交
  14. 28 9月, 2021 2 次提交
    • 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
    • Z
      fix: 中断中调用PRINTK概率卡死,导致系统不能正常响应中断 · 9726ba11
      zff 提交于
      当console层的打印缓冲buffer满且打印任务被饿死时,函数ConsoleOutput会出现在for循环中
      不退出的情况,导致中断打印时卡死
      
      close: #I4C9GC
      Signed-off-by: Nzff <zhangfanfan2@huawei.com>
      Change-Id: I70b9d7c848dce7d351c5679e7b08049df27a6f10
      9726ba11
  15. 27 9月, 2021 3 次提交
  16. 23 9月, 2021 1 次提交
    • H
      fix: 共享内存问题修复 · 9fdb80f8
      Haryslee 提交于
      Signed-off-by: NHaryslee <lihao189@huawei.com>
      背景:父进程移除共享内存并标记SHM_SEG_REMOVE,当子进程资源回收时在
      ShmFindSeg接口中判断该共享内存具有SHM_SEG_REMOVE时返回空,但是此时
      seg->ds.shm_nattch不为0,不应返回空。
      方案:ShmFindSeg接口中增加seg->ds.shm_nattch为0的判断。
      
      close #I47X2Z
      
      Change-Id: I8735cd11ac237b17fa745c50313da0fd0649bb9f
      9fdb80f8
  17. 18 9月, 2021 1 次提交
  18. 14 9月, 2021 1 次提交
  19. 13 9月, 2021 1 次提交
  20. 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
  21. 09 9月, 2021 1 次提交
  22. 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
  23. 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
  24. 31 8月, 2021 2 次提交
    • 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
    • C
      chore: optimize build scripts and add lto config entry · 055295b6
      Caoruihong 提交于
      Signed-off-by: NCaoruihong <crh.cao@huawei.com>
      Change-Id: Ibf8df58696b7f1ccb3b5b21154c3b94dda1e8ad2
      055295b6
  25. 30 8月, 2021 1 次提交
  26. 28 8月, 2021 1 次提交
  27. 26 8月, 2021 1 次提交
    • G
      fix: solve SIGCHLD ignored in sigsuspend() · 5a80d4e1
      Guangyao Ma 提交于
      在如下场景signal可能得不到及时处理:
      1、进程A设置信号a阻塞
      2、进程A收到信号a
      3、进程A调用sigsuspend结束阻塞
      原则上,步骤三应该立刻处理之前被阻塞的信号a,调用信号处理函数,并且sigsuspend
      返回。现在的问题是,信号a没有得到及时处理,并且进程A阻塞在sigsuspend()调用流程
      。
      本次修改,在1、2、3场景下,sigsuspend()处理过程中,如果发现已经收到信号,待处理
      时,会立刻进行调度切换,再次调度回来时,在调度模块中,会先主动处理已经收到的信
      号,最后sigsuspend返回用户态。
      
      close #I47CKK
      Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
      Change-Id: I1b30a938a2d18c3f58989d40eee0503ceffb27b5
      5a80d4e1
  28. 23 8月, 2021 1 次提交
  29. 22 8月, 2021 1 次提交
  30. 17 8月, 2021 1 次提交
  31. 14 8月, 2021 1 次提交
  32. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      wjj 提交于
      killpg:给进程组发信号
      waitid:等待进程结束
      修改测试用例到full里面
      
      Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
      Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094