1. 24 4月, 2022 1 次提交
  2. 27 9月, 2021 1 次提交
    • H
      fixed 9fdb80f8 from https://gitee.com/harylee/kernel_liteos_a/pulls/628 · 42fdaffe
      Haryslee 提交于
      fix: 共享内存问题修复
      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
      42fdaffe
  3. 26 9月, 2021 1 次提交
    • L
      fix: 修复sigwait等待到的信号值与获取的siginfo中的值不一致 · ed7defbd
      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
      ed7defbd
  4. 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
  5. 30 8月, 2021 1 次提交
  6. 28 8月, 2021 1 次提交
  7. 23 8月, 2021 1 次提交
  8. 22 8月, 2021 1 次提交
  9. 17 8月, 2021 1 次提交
  10. 14 8月, 2021 1 次提交
  11. 12 8月, 2021 1 次提交
    • W
      feat: 支持killpg和waitid · dc3cc094
      wjj 提交于
      killpg:给进程组发信号
      waitid:等待进程结束
      修改测试用例到full里面
      
      Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
      Signed-off-by: Nwjj <502004968@qq.com>
      dc3cc094
  12. 11 8月, 2021 1 次提交
    • G
      feat(vfs): vfs支持FD_CLOEXEC标记 · 27dca4d8
      Guangyao Ma 提交于
      首先,POSIX规范规定文件描述符需要支持close-on-exec属性,修改前的vfs不支持close-on-exec,当exec系列函数执行时,进程所有的文件将会被关闭(0,1,2也重新被打开)。但是,系统有些时候是不能在exec时关闭全部文件的,例如在执行exec之前,就需要重定向进程的某些文件描述符时(使用dup2),就希望该文件不被关闭,继续保持重定向属性,shell执行进程并重定向其标准输出到文件,这是我们经常做的事情。
      
      BREAKING CHANGE:
      执行exec类函数后,进程拥有的文件描述符情况发生变化:修改前,默认关闭所有的进程文件描述符,0,1,2重新打开;修改后,除非文件描述符拥有FD_CLOEXEC标记,否则该描述符不会被关闭。
      
      re #I3U81W
      
      Change-Id: I54e841ac88e9835ec23e97de0cbc906c4e11f5a4
      Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
      27dca4d8
  13. 10 8月, 2021 2 次提交
    • H
      fix: 合并进程栈两个地址连续的region · 42f374dd
      Haryslee 提交于
      背景:进程加载的时候,先预申请一个页用作参数拷贝,另外通过mmap方式申请
      额外的虚拟栈空间,此时便有两个地址连续的区间。
      方案:新增内部接口OsStackAlloc,用于申请一个连续的虚拟地址区间,并对其
      中指定区间做物理内存的映射。
      
      close #I43QYJ
      Signed-off-by: NHaryslee <lihao189@huawei.com>
      Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
      42f374dd
    • Z
      fix: 修改DoNanoSleep 以纳秒为单位 · 6917e084
      zhushengle 提交于
         DoNanoSleep 接口以微秒为单位,纳秒级别的在转换成微秒时被整除为0,
      导致转换成tick时为0,导致延时时触发yield,导致延时时间超大
      Close #I3Z9DP
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      Change-Id: Ib662fdc80707be6040b2bb06a1b457344bd48b30
      6917e084
  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. 05 8月, 2021 1 次提交
  17. 04 8月, 2021 1 次提交
  18. 03 8月, 2021 1 次提交
  19. 02 8月, 2021 1 次提交
  20. 30 7月, 2021 3 次提交
  21. 27 7月, 2021 1 次提交
  22. 22 7月, 2021 2 次提交
  23. 21 7月, 2021 2 次提交
  24. 20 7月, 2021 4 次提交
  25. 19 7月, 2021 1 次提交
  26. 16 7月, 2021 1 次提交
  27. 14 7月, 2021 4 次提交
    • Q
      feat: 给开发者提供系统信息导出Hidumper工具。 · cb17fa50
      qidechun 提交于
      给开发者提供系统信息DUMP机制,帮助开发者观察系统功能状态,发现潜在问题。
      
      Close #I3NN7D
      Signed-off-by: Nqidechun <qidechun@huawei.com>
      cb17fa50
    • G
      fix: 修改默认窗口宽度到400 · 09c491ca
      Guangyao Ma 提交于
      由于内核暂不支持tty,窗口默认宽度写死的为80。在流水线中,往往有时候需要更宽的
      窗口宽度。在tty支持动态获取和设置大小之前,先调整大小为400。
      
      re #I40LQX
      Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
      Change-Id: Ic21a8b7098f47b7d608762678eebb7b8ecb67ce4
      09c491ca
    • Q
      feat: add blackbox for liteos_a · a195aac9
      qidechun 提交于
      1、在内核增加BlackBox核心框架,对外提供模块回调接口注册和故障处理接口。
      2、增加默认的系统模块适配层,处理通用内核态和用户态故障日志抓取和保存。
      3、BBOX特性默认关闭,若想使用此特性,请在内核配置文件中增加如下编译选项:
      LOSCFG_BLACKBOX=y
      LOSCFG_SAVE_EXCINFO=y
      LOSCFG_SAVE_EXCINFO可以帮助抓取更多的故障日志。
      4、若已经打开BBOX特性,想快速验证此特性,请添加如下编译选项:
      LOSCFG_HIDUMPER=y
      
      Close #I406NP
      Signed-off-by: Nqidechun <qidechun@huawei.com>
      a195aac9
    • Z
      fix : futex requeue机制中,头节点的queueList 为NULL, 导致系统异常 · 1157c4a2
      zhushengle 提交于
          queuelist中的普通节点在调整为futexList的节点时,
      未校验其queueList的有效性,导致queueList未初始化,
      出现访问空指针;且在从旧链表迁移节点到新链表时,
      节点从旧链表删除之后又插入到另一个链表中,导致对
      旧链表的为NULL判断出错。
      
      Close #I4024F
      
      Change-Id: I506a10fc5740ce16e682c2c419b9d92a82000b86
      Signed-off-by: Nzhushengle <zhushengle@huawei.com>
      1157c4a2
  28. 09 7月, 2021 1 次提交