zhushengle
|
34814c58a3
|
feat: 支持IPC容器
BREAKING CHANGE:
支持ipc容器及增强对外变更:
1.clone 支持CLONE_NEWIPC
2.增加”/proc/[pid]/container/ipc" 用于查询容器信息
Close #I6AVMY
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I6a3c248d2d66a5342994c6e0b0aecddea8e32c72
|
2023-01-18 10:59:25 +08:00 |
zhushengle
|
20782299ce
|
feat: 支持pid容器
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: zhushengle <zhushengle@huawei.com>
Change-Id: I0895da9099cb285b3195af5e383d0fdeaf5c0087
Change-Id: I46a7642eeee73a4531c241e3ba6290dd302600a7
|
2023-01-11 11:13:34 +08:00 |
Far
|
987a722d2d
|
fix: 修复一些静态检查工具发现的问题
Signed-off-by: Far <yesiyuan2@huawei.com>
Change-Id: I2b93259d55a9eb1a9dfd5887fd7821c15274bb7f
|
2022-10-15 17:36:45 +08:00 |
yinjiaming
|
99ea8d4ed2
|
fix: 拼写错误修正
【背景】
代码中存在拼写错误
【修改方案】
修改存在拼写错误的地方
【影响】
对现有的产品编译不会有影响。
re #I5IA7P
Signed-off-by: yinjiaming <yinjiaming@huawei.com>
Change-Id: Idd5d7fc9705e5ec661596aa6533402e8d4a8a117
|
2022-07-21 11:05:11 +00:00 |
lihongjin
|
1c0de289ec
|
style: Misspelling
Signed-off-by: lihongjin <lihongjin1@huawei.com>
Change-Id: I13163f2e4d1e4b6e6c6bedaf9d4e705544df926b
|
2022-06-23 09:45:46 +08:00 |
zhushengle
|
eddcb840d3
|
feat: 支持调度框架
Close #I4Z3BL
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I5f32d1001ffabc0f725ce65b51ed9b3791e97f2b
|
2022-03-30 15:54:47 +08:00 |
zhushengle
|
65d5526c70
|
fix: 修复类型不匹配问题
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I31e16c9716de1223db7e4de916af3e010ca5f4e4
|
2022-03-24 11:24:34 +08:00 |
chenliming
|
ec3c8be6ee
|
chenliming@kaihongdigi.com: 队列支持变长读操作
Signed-off-by: chenliming <chenliming@kaihongdigi.com>
|
2022-03-22 18:36:24 +08:00 |
openharmony_ci
|
e26d969ca8
|
!751 OsFutexWait接口当absTime为0时,返回值不正确,导致用户态c库处理不当,触发当前线程卡死
Merge pull request !751 from zhangfanfan2/other
|
2022-03-21 04:03:26 +00:00 |
x_xiny
|
0f75bf01a6
|
fix:内源代码检视拼写错误修改
【背景】3.1代码review问题修改
【修改方案】
根据检视意见对拼写错误进行修改
Signed-off-by: xuiny <xuxinyu6@huawei.com>
Change-Id: I9fb982a8ba2052fa4d56e91eec33c96ab4035a90
|
2022-03-14 17:34:46 +08:00 |
zhushengle
|
dc479fb7bd
|
feat: 调度去进程化,优化进程线程依赖关系
1.移动LosTaskCB 至los_sched_pri.h, 解决调度与task的依赖关系
2.调度去进程化
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ibd3b618cee59f0b323e2b4fb14354c088b60b733
|
2022-01-27 14:30:50 +08:00 |
zhushengle
|
0e3936c4f8
|
feat: 调度相关模块间依赖优化
背景:
调度、线程、软件定时器、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: zhushengle <zhushengle@huawei.com>
Change-Id: Ia54dc1b8a4801a225a52e40555490c1dce0bd75e
|
2022-01-21 15:52:51 +08:00 |
zff
|
f504cc9145
|
fix: OsFutexWait接口当absTime为0时,返回值不正确,导致用户态c库不当处理,触发当前线程卡死
close: #I4KGO4
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I77d73836ec550828fd74ca84a13f83b1050316ac
|
2021-12-25 10:37:20 +08:00 |
kenneth
|
0f878febb7
|
chore: 修复社区反馈问题Percpu结构体注释错误
修复社区反馈问题Percpu结构体注释错误,排查下其他拼写错误。
close #I4GMLH
Signed-off-by: kenneth <zhushangyuan@huawei.com>
|
2021-11-10 10:20:33 +08:00 |
openharmony_ci
|
fcb21ffc8a
|
!676 修复ppoll接口"[ERR]OsMemFree check error!"报错
Merge pull request !676 from pef/ppoll-1
|
2021-11-02 09:35:09 +00:00 |
lnlan
|
2e3bbf1e61
|
修复ppoll接口"[ERR]OsMemFree check error!"报错
【背景】
1.内核中释放用户空间指针报错:"[ERR]OsMemFree check error!"
2.现有ppoll实现存在问题
3.相关用例需要整理
【修改方案】
1.去掉释放用户空间指针操作
2.更正逻辑错误
3.更正掩码设置与恢复不起作用
4.修复补充现有用例
【影响】
对现有的产品编译不会有影响。
re #I47YWZ
Change-Id: Ib2f60986e9cafb2ea5ef1097ab8552cbb1ede5b4
Signed-off-by: lnlan <lanleinan@163.com>
|
2021-11-02 07:04:35 +00:00 |
pef
|
78a297fd4e
|
修复ppoll接口"[ERR]OsMemFree check error!"报错
【背景】
内核中释放用户空间指针报错:"[ERR]OsMemFree check error!"
【修改方案】
修改SysPpoll函数。
【影响】
对现有的产品编译不会有影响。
re #I47YWZ
Change-Id: Id7f86036870d4f32be8fc438b9aad85cdda59546
Signed-off-by: pef <cyd1997@126.com>
|
2021-10-29 08:14:20 +00:00 |
zhushengle
|
5004ef4d87
|
fix: 优化liteipc任务状态,删除功能重复字段
LosTaskCB 中 字段waitFlag 用于专门记录任务被阻塞的原因,与ipcStatus 功能重复
Close #I4FVHK
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ie0998b987ba6e1db050596dec3b359e73ca47686
|
2021-10-29 12:02:00 +08:00 |
teamol
|
a55f68f957
|
fix: fix ppoll
1.modifications:
modified: syscall/fs_syscall.c
2.modify 2 testcases:
IO/full/IO_test_ppoll_001.cpp
IO/full/IO_test_ppoll_002.cpp
3.influence:
none
Signed-off-by: pef <cyd1997@126.com>
Change-Id: I85fc091098a6dfef1a4694a3bbc489640ee6dda2
|
2021-10-28 11:54:19 +00:00 |
openharmony_ci
|
7676cdb886
|
!656 修复PR520的修改缺陷
Merge pull request !656 from lnlan/sigwait_patch
|
2021-10-26 01:39:06 +00:00 |
lnlan
|
40338918d9
|
fix: 修复PR520缺陷
【背景】
https://gitee.com/openharmony/kernel_liteos_a/pulls/520
上面修改,信号处理时才会释放申请的内存,当信号被屏蔽,且一直发送该信号时,
内存占用会不断变大
【修改方案】
1.
信号发送时已经有该信号的siginfo在链表中时,不再重新申请,重复使用之前的siginfo.
【影响】
对现有的产品编译不会有影响。
re#I4DEG5
Signed-off-by: lanleinan <lanleinan@163.com>
Change-Id: I74b3b7ff0b9efb0179313af9a0c8d1e12d1db5bb
|
2021-10-11 12:37:58 +00:00 |
zhangfanfan2
|
3f71be7535
|
fix: OsFutexWaitParamCheck函数中absTime为0时,直接返回,不需要打印
当设置的超时时间比较短时,会出现absTime为0的情况,直接返回,不需要阻塞和打印。
close: #I4D67E
Signed-off-by: zff <zhangfanfan2@huawei.com>
|
2021-10-10 08:49:56 +00:00 |
openharmony_ci
|
93e74c5f0b
|
!520 修复sigwait等待到的信号值与获取的siginfo中的值不一致
Merge pull request !520 from lnlan/fixed_sigwait
|
2021-09-23 03:22:04 +00:00 |
lnlan
|
c3facd1b95
|
fix: 修复sigwait等待到的信号值与获取的siginfo中的值不一致
【背景】
集成测试发送两个不同的信号,sigwait第二次等到的仍是第一个信号
经定位,信号在kill时会将相关的siginfo信息拷贝到taskcb的unbinfo中,sigwait
处理时从unbinfo拷贝给用户。若此信号发送时处于屏蔽状态,再有其他信号发送会覆盖
掉unbinfo,此时sigwait等待这个信号获取到的info已经被覆盖
【修改方案】
1. 每个任务添加一个siginfo缓存链表,在处理信号前夕从缓存链表取出info到unbinfo中
【影响】
对现有的产品编译不会有影响。
re #I3M12H
Signed-off-by: lanleinan <lanleinan@163.com>
Change-Id: If4b064c18773f8eca7419c665977260167b09810
|
2021-09-10 03:21:58 +00:00 |
openharmony_ci
|
e095e87682
|
!574 fix: solve SIGCHLD ignored in sigsuspend()
Merge pull request !574 from MGY917/sigsuspend
|
2021-09-08 08:27:12 +00:00 |
LiteOS2021
|
dc9ec6856f
|
feat: L0-L1 支持Trace
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: LiteOS2021 <dinglu@huawei.com>
Change-Id: I6a8e64794c4852f2c2980993a06180e09ec6ee0d
|
2021-08-31 20:29:45 +08:00 |
Guangyao Ma
|
5a80d4e1a3
|
fix: solve SIGCHLD ignored in sigsuspend()
在如下场景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: Guangyao Ma <guangyao.ma@outlook.com>
Change-Id: I1b30a938a2d18c3f58989d40eee0503ceffb27b5
|
2021-08-26 15:36:13 +08:00 |
wjj
|
dc3cc094a7
|
feat: 支持killpg和waitid
killpg:给进程组发信号
waitid:等待进程结束
修改测试用例到full里面
Change-Id: Ice058ab4a6eede8ecbaacea0894c2161e3b9dce2
Signed-off-by: wjj <502004968@qq.com>
|
2021-08-12 18:06:55 +08:00 |
zhushengle
|
6917e08431
|
fix: 修改DoNanoSleep 以纳秒为单位
DoNanoSleep 接口以微秒为单位,纳秒级别的在转换成微秒时被整除为0,
导致转换成tick时为0,导致延时时触发yield,导致延时时间超大
Close #I3Z9DP
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ib662fdc80707be6040b2bb06a1b457344bd48b30
|
2021-08-10 11:25:49 +08:00 |
YOUR_NAME
|
35a2f3af33
|
fix: init进程收到子进程退出信号后,调用fork重新拉起进程,会导致系统卡死
问题原因:init进程执行信号时,线程栈底预留了部分空间给信号上下文使用,
从而导致处理信号时线程栈底比线程控制块里面记录的大,这样在fork的过程中内核
从init线程栈底copy线程上下文给新进程时,copy的不是实际运行的栈底,以致于
新进程的线程上下文不对,在实际运行时跑飞,引发系统卡死。
解决方案:在fork过程copy线程上下文时,判断是否预留了信号上下文空间,如果预留
了,则copy的栈底要基于预留后的栈底去copy线程上下文。
close: #I41HOY
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I61cb05183c78919730e3a68c1c85b72fa1decd16
|
2021-07-20 21:11:12 +08:00 |
openharmony_ci
|
d9ed4b4bf6
|
!427 fix: 修复lwip2.0 增强在futex中异常挂死问题
Merge pull request !427 from zhushengle/futex
|
2021-07-15 01:54:41 +00:00 |
zhushengle
|
1157c4a289
|
fix : futex requeue机制中,头节点的queueList 为NULL, 导致系统异常
queuelist中的普通节点在调整为futexList的节点时,
未校验其queueList的有效性,导致queueList未初始化,
出现访问空指针;且在从旧链表迁移节点到新链表时,
节点从旧链表删除之后又插入到另一个链表中,导致对
旧链表的为NULL判断出错。
Close #I4024F
Change-Id: I506a10fc5740ce16e682c2c419b9d92a82000b86
Signed-off-by: zhushengle <zhushengle@huawei.com>
|
2021-07-14 09:30:49 +08:00 |
openharmony_ci
|
d7387508e3
|
!402 消除编译告警
Merge pull request !402 from x_xiny/master
|
2021-07-09 08:37:20 +00:00 |
x_xiny
|
e4ff04586f
|
fix:消除编译告警
【背景】
消除编译告警
【修改方案】
消除编译告警
re #I3ZC1R
Change-Id: I594d0f57e4cbbdb246a6bef1c978a38228123a34
Signed-off-by: x-xiny <1301913191@qq.com>
Change-Id: I1d75cdcdcf9d06ec28e541cdfea77300da7c6bb1
|
2021-07-08 20:30:33 +08:00 |
Caoruihong
|
ac8c2c6d5b
|
fix: minimal compile
fix compile errors in minimal compilation
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I48f4f7b27c684e2c747c1949776c5c4f9e383dec
|
2021-07-07 00:26:33 +08:00 |
boxi
|
4e4f2d6d7e
|
refactor: 对LiteOS_a内核中menuconfig开关的宏使用#ifdef/#ifndef做预编译处理
LiteOS_a中有部分配置宏进行了重复冗余定义,导致当头文件未被包含时,极易引入错误,
故对menuconfig配置宏进行统一处理,均使用#ifdef/#ifndef作为预编译判断方式
Close #I3YEGS
Change-Id: Ife6db770cc66de1d6199a4f3ba3950e9bfd0e71a
Signed-off-by: boxi <lewis.liulei@huawei.com>
|
2021-07-01 09:08:18 +08:00 |
Kenneth
|
81f3d59717
|
chore: fix typos
fix typo destroy
close https://gitee.com/openharmony/kernel_liteos_a/issues/I3RR17
Signed-off-by: Kenneth <459864689@qq.com>
|
2021-06-16 14:52:06 +08:00 |
openharmony_ci
|
2067b2f648
|
!256 fix: 解决kill进程时无法保证进程持有的系统资源合理释放
Merge pull request !256 from zhushengle/Sig
|
2021-06-03 17:00:00 +08:00 |
zhushengle
|
cf89f016e9
|
fix: 解决kill进程时无法保证进程的已持有的内核资源合理释放.
背景: 当前信号实现原理是在系统调用结束和中断结束时检查是否有信号处理,
如果有信号处理就切去处理信号,信号处理结束后回来继续按原来流程执行。
问题:当用户态线程在执行系统调用或缺页异常时,运行在内核态,如果此时有信
号需要处理,且该线程已经持有了部分内核资源(如:锁,内存等), 此时如
果有中断发生,则在中断结束时,就会去处理该信号,此时用户态线程持有
了内核未释放的资源跑到了用户态去运行,如果该线程在用户态出现问题,
那么它持有的内核资源就无法被释放了。
方案:用户态线程在执行系统调用和缺页异常时暂时屏蔽信号,防止此时有中断去
处理信号,等系统调用结束或缺页异常结束时再去处理信号。
解决的问题:
1. 执行系统调用或缺页异常时屏蔽信号,防止中断去处理信号
2.解决无法kill 因为用户态的锁、ipc等阻塞的用户态线程
3.进程退出方式转变为: 依次通过kill去杀死该进程的所有线程
Close #I3S0N0
Change-Id: I0c48b9c89382826191b8a9326c71b57ba84124c2
|
2021-05-24 14:29:37 +08:00 |
openharmony_ci
|
3f16f1684a
|
!248 fix: fix length typo
Merge pull request !248 from kenneth/los_queue.h
|
2021-05-22 09:13:46 +08:00 |
openharmony_ci
|
9b364500ad
|
!252 删除冗余宏定义OFFSET_OF_FIELD
Merge pull request !252 from JerryH/list
|
2021-05-21 09:54:18 +08:00 |
arvinzzz
|
8cde768588
|
refactor: Refactored the kernel boot process and added a init framework
close: #I3I768
Change-Id: I4f801df4abe1a9afdf43391c28276e96a5e81513
|
2021-05-20 16:45:43 +08:00 |
kenneth
|
2b643b04c1
|
fix:fix queuePosition typo
|
2021-05-19 14:05:28 +08:00 |
YOUR_NAME
|
9b4129c949
|
Remove redundant macro definition(OFFSET_OF_FIELD)
Close #I3QMN1
Change-Id: I0ddd0c4474f5f6b5a2b1dd6608d642167b5548e6
|
2021-05-19 11:20:09 +08:00 |
kenneth
|
a68295d2a9
|
fix:change queuePosion to queuePosition
|
2021-05-19 08:38:33 +08:00 |
openharmony_ci
|
29fc5b3e3d
|
!236 fix: modify event API description
Merge pull request !236 from MGY917/event
|
2021-05-15 10:05:46 +08:00 |
Guangyao Ma
|
937734b1e9
|
fix: modify event API description
Change-Id: I131c70e52d907b6c52232596475f2dba16612fce
|
2021-05-11 21:09:24 +08:00 |
zhushengle
|
1e308db64e
|
fix:Fixed exception not saving stack pointer of SVC mode and abnormal signal processing issues
Close #I3OAFR
Change-Id: I25b14572809b6fabb9e9d17de89a99047c02a59b
|
2021-05-11 09:58:54 +08:00 |
zhushengle
|
6d63f75e7f
|
fix:Solve the coupling between the kernel and the structure under ARCH.
Close #I3OAFR
Change-Id: Icea238e20adf402d0ec1fc7e47ff4e58124a5e83
|
2021-04-26 19:54:49 +08:00 |
Guangyao Ma
|
deaa564a66
|
fix: dereference NULL point bug fix
Change-Id: Ib068696c9280105e209469e875c187d741b704d2
|
2021-04-25 11:47:05 +08:00 |