Skip to content

K
Kernel Liteos A

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

Fork自 OpenHarmony / Kernel Liteos A

通知 1
Star 1
Fork 0
K
Kernel Liteos A

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

切换分支/标签
  1. 09 6月, 2021 2 次提交
  3. 08 6月, 2021 3 次提交
    • G
      refactor(mksh): reduce the mksh size by Oz · 565b2e85
      由 Guangyao Ma 提交于 
      clang不支持“-flto,-Oz”作为链接选项，但是可以作为编译选项，且作为编译选项时，有更好的size减少效果。这里为了使用这种
编译选项组合，且为了不影响链接过程（Build.sh链接时也会使用CFLAGS），在链接选项生效的-O选项中，重置其为O2。
最终size可以从300+k,缩减为不到180k。

Close #I3UVEV

Change-Id: If29ac4a058bcd40c4c36deb484c9468c93bcd1ec
Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com>
      565b2e85
    • O
      !302 fix: Codex告警清零 · 1a3f3f54
      由 openharmony_ci 提交于 
      Merge pull request !302 from Far/master
      1a3f3f54
    • O
      !300 codex问题修复 · 7d100571
      由 openharmony_ci 提交于 
      Merge pull request !300 from LeonChan/master
      7d100571
  5. 07 6月, 2021 6 次提交
    • O
      !303 对toybox侵入式修改进行分离 · a94c6b09
      由 openharmony_ci 提交于 
      Merge pull request !303 from Kiita/toybox_porting_210607
      a94c6b09
    • O
      !296 支持最小化特性编译，添加了一个针对qemu arm virt的样例config配置 · 647f3def
      由 openharmony_ci 提交于 
      Merge pull request !296 from Caoruihong/master
      647f3def
    • C
      fix: codex · 101a55d1
      由 chenwei 提交于 
      1，VFS代码中不修改参数增加const修饰
2，fs_file_mapping.c: 增加安全函数的判空
3，path_cache.c: sizeof改为使用类型
4，fs_syscall.c: 对NULL解引用
5，VnodeLookup：冗余的判空，及不正确的判空

close: I3UMWD
Signed-off-by: Yansira's avataryansira <yansira@hotmail.com>
      101a55d1
    • Yansira's avatar
      refactor: 对toybox侵入式修改进行分离 · 09756fe5
      由 Yansira 提交于 
      【背景】当前liteos_a支持的toybox命令与linux存在差别，需要特别实现，为
避免侵入式修改，采用porting的方式将修改分离。

【修改方案】
在third_party/toybox下新增porting目录，以达到分离修改的目的。本次修改
基于porting目录且只涉及liteos目前支持的命令文件。

re #I3UQCK
Signed-off-by: Yansira's avataryansira <yansira@hotmail.com>
Change-Id: I15d5835e25d5b5de6e0a6f888c87264c2f886cdf
      09756fe5
    • L
      fix(kernel_test): 内核mem/shm冒烟用例重复运行失败 · 0676578a
      由 lnlan 提交于 
      【背景】内核mem/shm冒烟用例概率性失败门禁中shm冒烟用例失败，经验证
与构建，不符合预期

【修改方案】
原内核用例的源文件是通过框架自带的source_set（一种虚拟静态库）的方式组织的，
不受unittests（自定义的一种方式）控制，修改为文件列表直接加入到unittest中。

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

re #I3TH4W
Signed-off-by: Nlnlanc <lanleinan@163.com>
Change-Id: If5452adb033c17ee0d7c7f683968fe53013ee289
      0676578a
    • F
      fix: codex clean · b5370af8
      由 Far 提交于 
      1. 修复可能对NULL指针解引用的场景
2. 将不修改内容的指针入参修改为const
3. 对getpgrp的返回值进行校验后再使用
4. 修复了局部变量未初始化的问题

Close #I3UOFN
Signed-off-by: NFar <yesiyuan2@huawei.com>
      b5370af8
  7. 05 6月, 2021 2 次提交
  9. 04 6月, 2021 11 次提交
  11. 03 6月, 2021 7 次提交
  13. 02 6月, 2021 2 次提交
  15. 29 5月, 2021 1 次提交
    • L
      feat(build): 使用xts -notest选项时，内核用例不参与编译构建和用例编译配置方式调整 · 9bdf7164
      由 lnlan 提交于 
      【背景】
1.编译新增-notest选项为了排除用例参与构建，使用该选项时内核用例仍会参与构建，不符合预期
2.用例编译配置选项太多，需调整优化
【修改方案】
1.原内核用例的源文件是通过框架自带的source_set（一种虚拟静态库）的方式组织的，
不受unittests（自定义的一种方式）控制，修改为文件列表直接加入到unittest中。
2.编译配置通过level控制
【影响】
对现有的产品编译不会有影响。

Change-Id: I2c6a96e7276346de96f222b725d417418ff0e537
      9bdf7164
  17. 24 5月, 2021 1 次提交
    • Z
      fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放. · cf89f016
      由 zhushengle 提交于 
      背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
      如果有信号处理就切去处理信号，信号处理结束后回来继续按原来流程执行。
问题：当用户态线程在执行系统调用或缺页异常时，运行在内核态，如果此时有信
      号需要处理，且该线程已经持有了部分内核资源(如：锁，内存等), 此时如
      果有中断发生，则在中断结束时，就会去处理该信号，此时用户态线程持有
      了内核未释放的资源跑到了用户态去运行，如果该线程在用户态出现问题,
      那么它持有的内核资源就无法被释放了。
方案：用户态线程在执行系统调用和缺页异常时暂时屏蔽信号，防止此时有中断去
      处理信号，等系统调用结束或缺页异常结束时再去处理信号。
解决的问题：
  1. 执行系统调用或缺页异常时屏蔽信号，防止中断去处理信号
  2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
  3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程

Close #I3S0N0

Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
      cf89f016
  19. 22 5月, 2021 1 次提交
  21. 21 5月, 2021 4 次提交