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
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
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
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
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
mucor
73a777777e
fix: remove redundant headfile
...
1.remove redundant headfile in kernel, such as:
compiler.h;debug.h;automount.h;inode.h;syslog.h;net.h;
2.split fs.h to file.h and driver.h
3.move vnode.h and path_cache.h to vfs/include
4.remove redundant interface and defines
close: #I3RTNR
Signed-off-by: mucor <mucorwang@gmail.com>
2021-06-19 17:32:47 +08:00
kenneth
f0b419099d
chore: rename function OsCreateUserVmSpace
...
rename function OsCreateUserVmSpace to fix typo
close https://gitee.com/openharmony/kernel_liteos_a/issues/I3QD42
Signed-off-by: kenneth <459864689@qq.com>
2021-06-16 15:00:53 +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
Caoruihong
7e73c929a2
remove __cplusplus guards in .c files
...
Change-Id: I052d930d54e63179b17b77f02c107a015f3cfc3f
2021-04-19 18:28:25 +08:00
mamingshuai
73a7b66116
update openharmony 1.0.1
2021-03-11 18:43:57 +08:00
Caoruihong
63bd69267a
drop unnecessary executable file permission mode
...
Change-Id: Ia6c1f6302407a707b3ec9b805f4c92d8a7970b86
2020-10-13 16:37:25 +08:00
Harylee
f62115dfef
Fix mmap
2020-09-28 16:32:18 +08:00
wenjun
6df931fc98
add OpenHarmony 1.0 baseline
2020-09-08 17:22:24 +08:00