- 09 9月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !605 from Zhaotianyu/0902dir_refactor
-
- 08 9月, 2021 5 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !593 from MGY917/sync
-
由 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
-
由 openharmony_ci 提交于
Merge pull request !574 from MGY917/sigsuspend
-
由 openharmony_ci 提交于
Merge pull request !595 from MGY917/dyload_fd
-
由 Guangyao Ma 提交于
新增sync方法,该方法每次调用,会遍历系统内所有的mount点,调用各个文件系统注册 的sync方法,完成对所有已挂载文件系统的sync操作。 close #I480HV Signed-off-by: NGuangyao Ma <guangyao.ma@outlook.com> Change-Id: I57ced9c3f7685a448defd17ae56c842796b5668f
-
- 07 9月, 2021 1 次提交
-
-
由 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
-
- 03 9月, 2021 1 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !551 from Denny/remove_todolist
-
- 02 9月, 2021 3 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !600 from Caoruihong/opt_20210902
-
由 openharmony_ci 提交于
Merge pull request !598 from LiteOS/master
-
由 Caoruihong 提交于
You can specify another config file in hb build like this: hb build --gn-args liteos_config_file=myconfig.config file specified in liteos_config_file argument is relative to "$product_path/kernel_configs" directory, or is an absolute file path, for example: hb build --gn-args liteos_config_file=//path/to/myconfig.config or hb build --gn-args liteos_config_file=/another/path/to/myconfig.config Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I7e98604006feff9c2487e06a8f3f2a11e5de746b
-
- 01 9月, 2021 5 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !596 from Caoruihong/opt_20210901
-
由 Caoruihong 提交于
$(DEVICE_PATH)/drivers/Kconfig is mandatory now. Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Ie9484229e2dc6e6babe0cf2daf8e4f6693163052
-
由 openharmony_ci 提交于
Merge pull request !597 from Caoruihong/opt_kconfig
-
由 LiteOS2021 提交于
Signed-off-by: NLiteOS2021 <dinglu@huawei.com> Change-Id: Ie4555c57f56c82f74b5e29f0e58aec97dc6cc32d
-
由 Caoruihong 提交于
config files under tools/build/config directory are no maintained any more, so we delete all of them. Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Idf51d55caa3c820617b7c90affda0186718632e5
-
- 31 8月, 2021 6 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !565 from LiteOS/master
-
由 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
-
由 openharmony_ci 提交于
Merge pull request !586 from jason_gitee/master
-
由 openharmony_ci 提交于
Merge pull request !588 from 马帅/master
-
由 openharmony_ci 提交于
Merge pull request !590 from Caoruihong/lto
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Ibf8df58696b7f1ccb3b5b21154c3b94dda1e8ad2
-
- 30 8月, 2021 3 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !579 from Caoruihong/optimize_build_scripts
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Ibb4223ef2d032a03950263b766414ca1c021e69a
-
由 openharmony_ci 提交于
Merge pull request !570 from guweijie/gwj-kernel-ppoll-20210825
-
- 28 8月, 2021 3 次提交
-
-
由 jason_gitee 提交于
Signed-off-by: Njason_gitee <yangjie140@huawei.com>
-
由 maltose214 提交于
Signed-off-by: Nmaltose214 <mashuai3@huawei.com>
-
由 openharmony_ci 提交于
Merge pull request !573 from Caoruihong/v21.02
-
- 27 8月, 2021 5 次提交
-
-
由 openharmony_ci 提交于
Merge pull request !571 from wangjianjun/sys
-
由 openharmony_ci 提交于
Merge pull request !561 from guweijie/gwj-kernel-20210819
-
由 openharmony_ci 提交于
Merge pull request !544 from wangjianjun/waitid
-
由 openharmony_ci 提交于
Merge pull request !543 from wcc/fs
-
由 teamol 提交于
1.modifications: modified: syscall/los_syscall.h modified: syscall/misc_syscall.c modified: syscall/syscall_lookup.h 2.add 3 testcases: testsuites/unittest/IO/full/IO_test_ppoll_001.cpp testsuites/unittest/IO/full/IO_test_ppoll_002.cpp 3.influence: none Signed-off-by: Nteamol <28105285@qq.com>
-
- 26 8月, 2021 2 次提交
-
-
由 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
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: I5cdca0ee82d3e8a164120fe3ecb6e94f2f89d600
-
- 25 8月, 2021 3 次提交
-
-
由 wjj 提交于
把测试用例放在full中,需要依赖文件group和passwd,放在/etc下 Change-Id: Ie038b64db96180b52ee10d70d494da42207d3b92 Signed-off-by: Nwjj <502004968@qq.com>
-
由 openharmony_ci 提交于
Merge pull request !569 from Caoruihong/mksh_toybox
-
由 Caoruihong 提交于
Signed-off-by: NCaoruihong <crh.cao@huawei.com> Change-Id: Ie152b0ad21af5dc8e8c31c71f236500e5726e1c4
-
- 24 8月, 2021 2 次提交
-
-
由 wcc0 提交于
add fchdir and testcases Change-Id: Iad724944e727c4a08b8801f109acbbe48f55c283 Signed-off-by: Nwcc0 <917033401@qq.com>
-
由 openharmony_ci 提交于
Merge pull request !504 from phchang/updateclock
-