1.1K Star 6.1K Fork 4.9K

OpenHarmony / docs

 / 详情

鸿蒙架构设计探讨

已完成
任务
创建于  
2020-09-30 10:11

技术探讨:

一位外国工程师朋友针对鸿蒙咨询了如下问题,麻烦社区帮忙看看。我这边看了下,反馈解耦不彻底(二进制引用源文件,编译出错不终端,编译选项设计不独立等,文件路径引用多种样式)。
还有vendor,driver文件摆放位置不规范等等。
能帮忙答复下这些问题么?

  1. .json files to configure HarmonyOS build
    .json files are required by python build scripts for system components configuration. What is the reason for that? Is there a way to generate those files from some human readable format? Why is this a preferred way of configuring the system's build?
    json文件配置鸿蒙的编译系统
    python构建脚本需要使用json文件,用于系统组件配置。为什么要这样处理?有没有方法从更易读的格式生成这些文件?为什么json文件配置系统构建的首选方法?

  2. Kernel configuration options
    Why do kernel configuration options exist if most of them cannot be turned off? For instance, one can't disable FS_VFS_, COMPAT_POSIX, COMPAT_BSD otherwise the kernel won't build due to strong dependencies. It seems that there are cross dependencies between separate modules inside of the kernel code. For example, low-level memory management uses file system code. There is no clear isolation between some kernel components which makes it nearly impossible to exclude them from the build. Is that a mistake in design and should be changed or options that disable components crucial for the kernel build should be statically enabled without possibility to change?
    内核选项
    为什么内核配置选项大部分都无法关闭?例如,不能禁用FS_VFS_、COMPAT_POSIX、COMPAT_BSD这些选项,否则内核将由于强依赖性而无法构建。似乎内核代码内部的独立模块之间存在交叉依赖。例如,内存管理使用文件系统代码。某些内核组件之间没有明确的隔离界限,因此几乎不可能将它们排除在构建之外。这是设计中的错误,应该更改。还是禁用对内核构建关键组件的选项应该静态使能,而不能做更改?

  3. Third party libraries
    Why third party libraries, such as musl or nuttx, are outside of the kernel directory if:
    a) They are not vanilla versions and are modified or include kernel headers directly.
    b) Paths to those directories are either hard coded in the liteos build ("../../") or are kept as symbolic links in the liteos tree (musl). Why multiple ways of including those libs into the kernel?
    为什么第三方库(例如musl或nuttx)位于内核目录之外,如果:
    a)不是普通版本,而是直接修改或包含内核头。
    b)这些目录的路径要么是硬编码在liteos构建(../../")中,要么是作为符号链接保存在liteos目录(musl)中。为什么有多种方法将这些库包含到内核中?

  4. Vendor directories
    Kernel build depends strongly on vendor directory, that resides outside of the kernel. In some cases, such as wifiiot target, kernel files are stored in vendor. Generic drivers such as ARM UART PL011 include chip specific files from vendor. Generic kernel code depends on platform specific, HiSilicon files and functions. What is the reason of keeping vendor directory outside of the kernel if it
    a) contains liteos kernel code
    b) is required for the kernel to build
    c) cannot be re-used due to dependency on liteos

  5. Behavior when build fails
    Why failed build continues until the end and when retrying build removes previously created files? Is there a way to not rebuild everything from scratch when the build fails and gets re-started after solving the problem in the source code?
    为什么编译失败了,编译还会一直持续到结束。并且重新编译会删除以前创建的编译中间文件?有没有办法在构建失败并解决问题后,再次编译不从头开始重建所有内容?

  6. What is the real meaning of liteos_a and liteos_m ?
    Is A for application processors and M for microcontrollers? If so, why there seems to be liteos_riscv as a parallel kernel type used interchangeably with liteos_m in the build system?

  7. Harmony liteos_m vs LiteOS
    We can see that Harmony liteos contains files, function names, etc. no longer present in gitee LiteOS. In the latter one, the change was applied in the following commit: https://gitee.com/LiteOS/LiteOS/commit/f74e444138a4d811c2a8d606a252070de176267a
    Is there a reason for Harmony liteos to keep the old code base?
    我们可以看到,Harmony lieos中包含的文件、函数名等,不再存在于gite LiteOS中。在后一种系统中,有如下提交https://gitee.com/LiteOS/LiteOS/commit/f74e444138a4d811c2a8d606a252070de176267a
    而鸿蒙保留旧代码库有什么理由吗?

  8. Drivers
    What is the goal of keeping drivers directory in the HarmonyOS root directory? Are those drivers supposed to be used in the kernel or it is an unfortunate name for the userspace components?
    将drivers目录保留在HarmonyOS根目录下的目的是什么?这些驱动程序是应该在内核中使用的? 放置在用户空间不恰当

  9. File attributes
    Many files in the HarmonyOS tree has "executable" attribute. Why?
    很多文件在鸿蒙系统中拥有可执行的属性,为什么?

  10. Libraries in binary form
    We forcefully link with libraries in binary form such as libhi35xx_bsp.a. Because of that there is no way to disable some drivers as their init functions are called from the library in the binary form which then fails to link due to lack of related symbols. Why do we link with libraries in binary form if we have a source code for them?
    我们必须强制链接到二进制形式的库,如libhi35xx_bsp.a。因为它们的init函数被二进制形式库调用,我们禁用某些驱动程序,会因为缺少相关符号而无法链接。如果我们有一个二进制形式的库,为什么我们链接到它们的源代码。

  11. What are platforms in platform/Kconfig
    The description refers to "Boards" but it the macro definition it looks more like SoC. Which one is it?

评论 (11)

flyingfishercn 创建了任务
flyingfishercn 关联仓库设置为OpenHarmony/docs
flyingfishercn 修改了标题
flyingfishercn 修改了描述
NEEN 负责人设置为jinguang
NEEN 负责人jinguang 修改为wanchengzhen
NEEN 负责人wanchengzhen 修改为未设置
NEEN 添加了product-question(已删除)标签
jinguang 负责人设置为wanchengzhen
展开全部操作日志

问题都很有建设性,为什么没有鸿蒙的人回复?

开源太晚了,应该像谷歌那样从第一行代码开始开源,这样可以利用群众的智慧及早发现问题。

开源太晚了,应该像谷歌那样从第一行代码开始开源,这样可以利用群众的智慧及早发现问题。

@gmg137 没有早晚这种判定吧,什么最有效率就按照什么来

@hbc 架构设计一旦确定便不好更改,何况已经在一些硬件上应用了,积重难返。

开源太晚了,应该像谷歌那样从第一行代码开始开源,这样可以利用群众的智慧及早发现问题。

@gmg137 从第一行代码开源说的你就会有解决方案一样

鸿蒙的代码质量还有架构质量如何?看问题,架构一般般,代码质量还没看

@ycllz 666,架构一般般在何处,有啥建议不

感觉有些堆代码赶工的嫌疑

建议对flutter做适配

@天书 当下现状的话 这事不太可能

这些问题提的很中肯;我也有这些的疑问;
感觉整套东西,都是堆叠出来的,没有仔细考虑过架构的东西;

逐一回复一下:
1.json格式兼顾了读写性能以及可读性,所以选择了json。如果有更好的选择,欢迎推荐。
2.liteos-a需要保持FS_VFS_,COMPAT_POSIXX等,提供必需的兼容性,目前该内核还是OS的子系统服务的,这些都是必需的依赖。liteos-a并不是一个独立的内核,而是鸿蒙专用的内核
3.third_party在根目录,是openharmony内部指定的规则,里面包含的三方库是给所有子系统用的,而不是专为liteos-a使用的。
4.好意见,已经整改了
5.1.1.0之后的版本,通过hb提供了该功能,如果不使用hb -f(full),则只增量编译
6.liteos-a通常指带mmu的cpu,例如cortex-a7等;liteos-m通常指没有mmu的mcu,例如cortex-m4等
7.目前是两个分支,liteos_m和LiteOS今后会归一
8.Driver是个独立模块,存放HDF驱动框架,HDF框架和HDF驱动不一定跑在内核态
9.好意见,已经整改了
10.芯片厂家的提交,并不限制是否其开源,只要提供相应的驱动等适配就可以。而且整个openharmony具备友好的licnese,让厂家具备闭源的可能性
11.可参考device目录,这是定义了“Boards”的地方

NEEN 任务状态待办的 修改为已完成
NEEN 移除了product-question(已删除)标签

登录 后才可以发表评论

状态
负责人
项目
里程碑
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
开始日期   -   截止日期
-
置顶选项
优先级
预计工期 (小时)
参与者(10)
24256 gmg137 1578915532 112318 simenhi 1578918054 1032666 null 078 7444 1578938753 969128 artrener 1578937067 1568278 aiweline admin 1578954762 5260206 bmi yile 1578983381 606485 flyingfishercn 1642816142
其他
1
https://gitee.com/openharmony/docs.git
git@gitee.com:openharmony/docs.git
openharmony
docs
docs

搜索帮助