p71924506
/
kernel_liteos_a
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
956 Commits 12 Branches 12 Tags 9.1 MiB
Commit Graph

71 Commits

Author SHA1 Message Date
openharmony_ci 5db6c62313 !710 清理YES/NO宏 
Merge pull request !710 from Caoruihong/remove_yesno
 2021-11-18 09:32:42 +00:00
openharmony_ci fe4082ca9e !709 A核代码静态告警定期清理 
Merge pull request !709 from wangchen/1112_codex
 2021-11-16 06:47:22 +00:00
Caoruihong bba832ea08 chore: replace YES/NO macros to 1/0 
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I40e31e82c33418019c1afc16ac174919e72fbb07
 2021-11-16 01:27:06 +08:00
lnlan 9ba725c3d4 fix: A核代码静态告警定期清理 
【背景】A核代码静态告警定期清理

【修改方案】
1，根据codex等工具分析结果，进行必要的规范等问题修改

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

re #I4I0O8
Signed-off-by: wangchen <253227059@qq.com>
 2021-11-15 02:47:08 +00: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 9525ca2826 !697 修改blackbox生成的文件和文件夹权限 
Merge pull request !697 from mgceshuang/upload_teeee
 2021-11-08 02:27:30 +00:00
openharmony_ci 3b8083815c !701 按照门禁要求对所有BUILD.gn脚本进行格式化 
Merge pull request !701 from Caoruihong/gnformat
 2021-11-06 04:48:29 +00:00
Caoruihong a2fed9a56c chore(build): format all BUILD.gn files 
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: Ifd3bf13f53a27e0a0bbd051cf35662e7409e6ed0
 2021-11-06 11:55:58 +08:00
YOUR_NAME eedde91826 Modify folder and file permissions 
Signed-off-by: YOUR_NAME <mashuang9@huawei.com>
 2021-11-04 14:50:42 +08:00
zhushengle f06e090a10 feat: 进程cpup占用率结构优化为动态分配 
Close #I4GLNT
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I7f3dd61bbf014fa157b1f9a0a089fd985fe188c2
 2021-11-02 19:57:26 +08:00
zhushengle 52379242c1 feat: liteipc 静态内存优化 
Close #I4G4HP
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I259c792365d9747f391c5bd275e77f04b83e0792
 2021-11-02 11:54:08 +08: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
zhushengle 0f0e85b7a6 fix: 非当前进程销毁时，销毁liteipc时错误的销毁了当前进程的liteipc资源 
Close #I4FSA7
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I8b24a1e1554b4b867a841bc1b6765cbfd648cdbd
 2021-10-28 17:30:54 +08:00
shenchenkai c121d0eea3 Description:[fix] clean hilog/hievent ring buffer after memory verification failed 
Change-Id: I9310fe807ec95721be78deb60ed9728ef9b56e48
Signed-off-by: shenchenkai <shenchenkai@huawei.com>
 2021-10-22 17:00:10 +08:00
openharmony_ci bda00e6747 !655 TCB中使用的execFile字段改为execVnode 
Merge pull request !655 from LeonChan/execfile
 2021-10-15 01:45:58 +00:00
openharmony_ci d3b618887a !660 fix: 优化trace buffer初始化，删除swtmr 桩中的无效参数 
Merge pull request !660 from LiteOS/master
 2021-10-14 02:41:05 +00:00
LiteOS2021 b551270ef5 fix: 优化trace buffer初始化，删除swtmr 桩中的无效参数 
close #I4DQ1X
Signed-off-by: LiteOS2021 <dinglu@huawei.com>

Change-Id: I79b416720f5327749a5884a65a5e61db07f2a17c
 2021-10-14 09:47:11 +08:00
Haryslee 665c152c27 fix: 修复硬随机不可用时，地址随机化不可用问题 
方案：硬随机不可用时，默认使用软随机数代替硬随机数

close #I4D4TK

Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: Ia7d2a9583257d7b8041b8994a70a7c36149c33fb
 2021-10-11 10:00:08 +08:00
Leon Chan e4a06623ce fix: change the execFile field in TCB to execVnode 
TEE需要借用TCB中的execFile来校验打开的文件，pagecache修改后，可执行程序在mmap之后，会被立即关闭，因此将execFile改为execVnode

close: #I4CLL9

Signed-off-by: Leon Chan <chenwei26@huawei.com>
 2021-09-30 14:33:36 +08:00
Haryslee 06ea03715f feat: 支持AT_RANDOM以增强用户态栈保护能力 
背景：不开地址随机化时，用户态栈CANARY值是固定值
方案：支持AT_RANDOM，CANARY从AT_RANDOM获取随机值以增强用户态栈保护能力

close #I4CB8M

Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: I28cef09f7016a5096e2096d4f6aa72722fcf1fd7
 2021-09-30 10:36:12 +08:00
openharmony_ci 2c33cfce86 !599 feat: L0~L1 支持Perf 
Merge pull request !599 from LiteOS/perf
 2021-09-29 06:15:02 +00:00
LiteOS2021 6e0a3f10bb feat: L0-L1 支持Perf 
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: LiteOS2021 <dinglu@huawei.com>
Change-Id: Ieb9b7483c85d1495df7c55bc0027f4309dff9814
 2021-09-28 19:28:34 +08:00
openharmony_ci 7d7cff4c51 !633 fix: codex清理 
Merge pull request !633 from Far/master
 2021-09-27 08:38:37 +00:00
Far 9ab3e351d3 fix: codex 清理 
Close #I4BL3S

Signed-off-by: Far <yesiyuan2@huawei.com>
 2021-09-27 14:43:28 +08:00
Leon Chan a375bf5668 fix: close file when process interpretor failed 
close: #I4ATQX

Signed-off-by: Leon Chan <chenwei26@huawei.com>
 2021-09-18 15:02:22 +08:00
openharmony_ci ecd9ca7781 !534 pagecache从filep改为使用vnode 
Merge pull request !534 from LeonChan/pg
 2021-09-15 03:51:50 +00:00
Leon Chan 38a6b804e9 feat: page cache backed by vnode instead of filep 
1, change the owner of page to vnode
2, save the file path in vnode

close: #I44TBS
Signed-off-by: Leon Chan <chenwei26@huawei.com>
 2021-09-14 15:31:33 +08:00
arvinzzz b3d96d166c refactor: 清理Makefile冗余项 
清理Makefile冗余项，各模块Makefile里不需要再次引用公共路径，只需引用私有头文件路径

close: #I49MOO

Signed-off-by: arvinzzz <zhaotianyu9@huawei.com>
Change-Id: I2dd7189c866498896461f78bfed5444ae1d86876
 2021-09-13 18:14:15 +08:00
openharmony_ci ba977dd5ab !605 refactor: 内核目录结构整理 
Merge pull request !605 from Zhaotianyu/0902dir_refactor
 2021-09-09 01:23:33 +00:00
arvinzzz 33d0c1bd0b refactor: 内核目录结构整理 
1. 原kernel/common目录下属于内核拓展组件，统一移入kernel/extend管理
2. Kconfig分层，各模块自己的配置放到自己目录下管理
3. 原platform下不属于平台的公共代码抽到kernel/common下，只留板级链接脚本和一些编译脚本指向device目录下触发平台相关的编译
4. 对外公共头文件统一抽到对外include路径
5. 废弃宏，头文件清理

close: #I48KI4

Signed-off-by: arvinzzz <zhaotianyu9@huawei.com>
Change-Id: I0cf5ea81c92a8fa7b113da9cbdc8b7bc935f5aae
 2021-09-08 16:36:28 +08:00
openharmony_ci 597ced7948 !595 fix: dyload open close failed 
Merge pull request !595 from MGY917/dyload_fd
 2021-09-08 08:26:55 +00:00
Guangyao Ma 5e87d8c183 fix: dyload open close failed 
本次提交修复内核加载器，异常情况分支的一个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: Guangyao Ma <guangyao.ma@outlook.com>
Change-Id: Ifca809f88b5ffcfb879dc5520d1f6adf5cf92bcd
 2021-09-07 16:28:37 +08: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
Caoruihong df35eb513d chore(make): optimize build scripts 
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: Ibb4223ef2d032a03950263b766414ca1c021e69a
 2021-08-30 17:18:21 +08:00
Caoruihong 0e260949c9 feat(make): optimize makefiles and remove some unused files 
Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: Ie2dfa7334417ccd55bd56a19a7882a982ce49cab
 2021-08-22 04:23:40 +08:00
openharmony_ci 0f4d5a4b0c !287 feat(vfs): vfs支持FD_CLOEXEC标记 
Merge pull request !287 from MGY917/master
 2021-08-12 00:36:19 +00:00
Guangyao Ma 27dca4d857 feat(vfs): vfs支持FD_CLOEXEC标记 
首先，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: Guangyao Ma <guangyao.ma@outlook.com>
 2021-08-11 15:35:46 +08:00
Haryslee 42f374dd7a fix: 合并进程栈两个地址连续的region 
背景：进程加载的时候，先预申请一个页用作参数拷贝，另外通过mmap方式申请
额外的虚拟栈空间，此时便有两个地址连续的区间。
方案：新增内部接口OsStackAlloc，用于申请一个连续的虚拟地址区间，并对其
中指定区间做物理内存的映射。

close #I43QYJ

Signed-off-by: Haryslee <lihao189@huawei.com>
Change-Id: I224cca3671c42a94c2f74b2da5a11403849e33d3
 2021-08-10 17:20:17 +08:00
Caoruihong 4dc421e3de fix: liteipc max data size too small 
use IPC_IO_DATA_MAX from liteipc_adapter.h

Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I94f2dd2ff148e8a03ffb2c7b38ab06a34a2d2827
 2021-08-02 11:58:29 +08:00
Caoruihong 3b5268f02a chore: output liteos binaries to target_out_dir 
liteos binaries no need pack to rootfs.

Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: Iba650c9d09302902c108760163eca55b4ec40221
 2021-07-22 18:52:24 +08:00
Caoruihong a8805a65aa feat: add support for gn build system 
add BUILD.gn for all kernel modules

Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I018446427bf64615f2596d47862b219659b58b34
 2021-07-21 15:52:40 +08:00
openharmony_ci 003810284c !384 对内核中menuconfig开关的宏使用#ifdef/#ifndef来做预编译判断 
Merge pull request !384 from boxi/upload
 2021-07-01 07:11:13 +00: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
Caoruihong d7672d47f2 chore: make liteos_a can be built alone 
in the liteos_a directory, we used to use `make clean all` command
to build liteos_a kernel for test.

Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: I5ca689c1c44052f7de937d7faa9e4d3534d97380
 2021-06-30 18:44:46 +08:00
openharmony_ci abbeca1cb2 !359 sysroot和CPU架构参数通过BUILD.gn传递给Make 
Merge pull request !359 from Caoruihong/sysroot
 2021-06-29 08:14:54 +00:00
openharmony_ci 50c8abc521 !371 fix: 修复kill进程时，liteipc阻塞的进程无法退出问题 
Merge pull request !371 from zhushengle/p_kill
 2021-06-29 05:27:08 +00:00
openharmony_ci 339c467e71 !375 基于汇编实现内核对用户态内存清零的功能 
Merge pull request !375 from Harylee/mem
 2021-06-29 04:41:02 +00:00
Caoruihong 9e45086d19 chore: pass sysroot and arch related cflags by BUILD.gn 
sysroot and arch related cflags are pass by BUILD.gn now.

Signed-off-by: Caoruihong <crh.cao@huawei.com>
Change-Id: Ia6000dd7ed8a8a37e935ace49d8460a919a16566
 2021-06-28 16:31:02 +08:00
zhushengle 7de43bb004 fix: 修复kill进程时，因liteipc阻塞的进程概率无法退出问题 
kill进程时，会将因为liteipc阻塞的线程唤醒，使其调度并自动退出，由于liteipc阻塞机制为
循环阻塞方式，会导致将因liteipc阻塞的线程唤醒后又进入等待中。此处在唤醒因liteipc阻塞的
线程后检查是否已有kill标志，如果有使其按接收数据失败退出，在返回用户态之前，该线程会进
入退出流程，结束运行。

Close #I3XX7K

Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Iec4e298dff4aefd2994289067a35cb5673e323f9
 2021-06-26 17:08:48 +08:00
Haryslee 9db3407589 feat: 基于汇编实现内核对用户态内存清零的功能 
背景：LOS_UserMemClear接口原有实现是通过在内核中
申请一块堆内存并对其清零，调用copy_to_user来达到
对用户态内存清零的目的，需要使用堆内存。
修改方案：基于汇编实现内核对用户态内存清零的功能。

close #I3XXT0

Change-Id: I27cb1e45559cb75a9b330799fe427abd54f51c15
Signed-off-by: Haryslee <lihao189@huawei.com>
 2021-06-26 15:31:42 +08:00