【2022操作系统大赛功能挑战赛道】小米公司赛题解析
小米集团成立于2010年4月，是一家以智能手机、智能硬件和 IoT 平台为核心的消费电子及智能制造公司。小米目前是全球领先的智能手机品牌之一，2021年全球出货量达1.9亿台，创历史新高。同时，小米已经建立起全球领先的消费级AIoT物联网平台，截至2021年12月31日，AIoT平台已连接的IoT设备（不包括智能手机及笔记本电脑和平板）数达到4.34亿。集团业务已进入全球逾100个国家和地区。
小米在专注于智能手机、智能电视以及智能家居生态链建设的创新型科技的同时，也高度关注核心基础IT技术人才的培养，小米公司积极支持全国大学生系统能力大赛，根据大赛的目标，由Vela团队、TEE团队、Mina团队的专家提供了8个与实际场景相关的赛题。
对于选择小米公司赛题的同学，命题团队将指派专家进行悉心指导，专家将通过线上答疑、资料放送、技术培训与交流等方式为选手提供支持，具体参看各赛题详细内容。
此外，公司将为获奖同学开通入职绿色通道：
1)获得大赛总决赛二等奖与三等奖的同学可以免笔试。
2)获得大赛总决赛一等奖的同学除免笔试外还可直接免去所有技术面试。
有意向选择小米赛题的同学，可登录赛题库https://github.com/oscomp，了解赛题的详细信息，也可以直接联系赛题导师咨询。
第一部分：Vela团队赛题
Vela团队为本次大赛提供了4个赛题，这四个赛题均要应用到Vela平台和NuttX系统。Vela平台和NuttX系统的简单介绍如下：
关于Vela：
Vela(https://iot.mi.com/vela)
是小米公司基于开源实时操作系统NuttX打造的物联网嵌入式软件平台，Vela在各种物联网硬件平台上提供统一的软件服务，支持丰富的组件和易用的框架，用于打通碎片化的物联网应用场景。
关于NuttX：
(https://nuttx.apache.org/docs/latest/)
是一个在IoT、分布式嵌入式系统、无人机系统中广泛使用的RTOS，第一个版本由 Gregory Nutt 于 2007 年发布。NuttX 可以支持 8 位到64位的处理器，支持risc-v、arm、mips、x86等主流芯片平台，按照POSIX和 ANSI 标准进行设计，支持MMU和MPU，支持多线程和进程。2019年，NuttX在小米的推动下正式进入Apache基金会，小米多位资深工程师参与了NuttX社区
(https://github.com/apache/incubator-nuttx)
的开发和架构设计。经过多年的不懈努力，NuttX功能丰富，性能稳定，商业化成熟度高，在各种物联网产品上得到了广泛的应用。
01
【Proj179】基于Vela平台的NuttX RTOS多执行域实现
http://github.com/oscomp/proj179-xiaomi-nuttx-multidomain
【赛题难度】中-高
【赛题背景】
当前，智能汽车已列为我国的发展战略之一，是未来10年国家大力发展的支柱产业之一。而在汽车行业，国际标准化组织的功能安全性标准ISO26262在车机的软硬件系统中得到了广泛的接受和应用。其中，标准的第6部分中对软件的功能安全性机制做了标准定义，提出了3种保证软件互不干扰（freedom from interference）的机制标准，包括：
1.时序和执行安全性（Timing and execution）
2.内存保护安全性（Memory）
3.信息交换
（Exchange of information）
要达到这样的要求，需要在RTOS的软件架构层面上需要做出调整以进行适应。本项目引入执行域的概念，以Vela平台和NuttX实时操作系统为软件平台基础，结合大赛所提供的K210硬件平台（NuttX RTOS已经完整支持K210板卡），实现执行域的概念，对功能安全性的几个要求从架构上进行保证，以此基础来满足RTOS的功能安全设计要求。
【功能点】
所有功能点应能在K210板卡上运行并演示。软件架构图如下：
1.功能点要求
1）执行域管理负责各个执行域的创建，执行，加载和管理，以及执行域之间的通信机制
不同的执行域运行不同的NuttX RTOS实例，各个RTOS域之间具备独立的线程调度和执行空间。
2）但每个RTOS实例之间的代码段共享
4）每个执行域之间应做到弱耦合，某个执行域的崩溃，退出等异常不能影响其余执行域中实例的运行和调度，并应提供对该执行域的重启机制
2. 扩展功能点
在实现执行域的基础上，参考AUTOSAR和ISO26262，在NuttX上实现针对软件功能安全所定义的一种或几种安全机制。
【参考文档】
https://nuttx.apache.org/docs/latest/：NuttX的最新文档，可以直接下载并按照要求配置和使用K210板卡。
https://github.com/apache/incubator-nuttx/tree/master/boards/risc-v/k210/maix-bit：NuttX文档中对K210板卡的配置和使用说明。
iso26262标准，Part6
Overview of Functional Safety Measures in AUTOSAR:
https://www.autosar.org/fileadmin/user_upload/standards/classic/21-11/AUTOSAR_EXP_FunctionalSafetyMeasures.pdf
【参考代码】
https://github.com/apache/incubator-nuttx/：目前NuttX针对K210板卡具备完整支持，参赛者可在此基础上进行后续开发。
【预期目标】
下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
第一级：完成执行域的启动和加载，每个执行域可独立运行并输出log。
第二级：设计并指定一个主执行域，该执行域可用shell串口进入，并通过rpmsg的console通道查看别的执行域内部运行情况。
第三级：根据对iso26262和autosar标准的理解，实现其中的1~3种功能安全机制。
【指导专家】
接口人：秦蔚，[email protected]
小米公司Vela研发团队（含NuttX社区主要代码提交人）
【对选择该赛题的支持】
技术答疑指导：针对NuttX实时操作系统和Vela平台提供业界最专业权威的技术支持和指导、提供小组答疑会和试题技术方案的实现思路指导。
技术资料支持：提供相关技术资料和对应索引，以及k210板卡Vela调试和使用环境搭建指导。
线上技术培训：提供线上的NuttX RTOS总体培训讲解，并对试题相关部分进行针对性讲解。
赛题方向指引：我们希望参赛团队根据自己的理解和思路，完成相关的代码架构设计，我们可以进行代码架构的评估和建议和以及针对NuttX修改思路上的指导。
获奖激励：对于优秀的二等奖以上获得者，提供小米Vela操作系统团队北京和武汉的实习机会，直接参与小米开源操作系统的开发工作，面对面和开源社区大神进行技术交流，相关成果经审核后可进入NuttX开源社区
入职礼包：优秀的获奖者入职后可以提供入职礼包（一套基于Vela系统的智能家居产品）。
02
【Proj180】基于Vela平台的NuttX RTOS Rust增强
http://github.com/oscomp/proj180-xiaomi-nuttx-rust-enhance
【赛题难度】中-高
【赛题背景】
Rust是一门系统编程语言，专注于安全，尤其是并发安全，支持函数式和命令式以及泛型等编程范式的多范式语言。Rust在语法上和C++类似 ，但是在保证性能的同时会提供更好的内存安全机制。当前，Rust语言已经逐步成为Linux内核的基础开发语言之一，后续将在Linux内核的开发中发挥重要作用，并会在后续的系统软件的开发中起到重要作用。
以Vela平台和NuttX实时操作系统为软件平台基础，结合大赛所提供的K210硬件平台（NuttX RTOS已经完整支持K210板卡，仿照Linux内核的实现方式，对NuttX操作系统进行增强，扩展各种Rust支持。
【功能点】
所有功能点应能在K210板卡上运行并演示。
1. 功能点要求
仿照Linux内核的实现，完成NuttX整体Rust支持框架包括编译框架。
编写示例的Rust应用程序，可以在NuttX中进行加载和执行。
编写示例驱动，可以采用模块方式加载内核驱动到NuttX内核并运行。
2.扩展功能
扩展Rust的支持，给出参考实现框架。
利用Rust重写NuttX中的某个子系统框架。
【参考文档】
https://nuttx.apache.org/docs/latest/：NuttX的最新文档，可以直接下载并按照要求配置和使用K210板卡。
https://github.com/apache/incubator-nuttx/tree/master/boards/risc-v/k210/maix-bit：NuttX文档中对K210板卡的配置和使用说明。
https://security.googleblog.com/2021/04/rust-in-linux-kernel.html。
【参考代码】
https://github.com/apache/incubator-nuttx/：目前NuttX针对K210板卡具备完整支持，参赛者可在此基础上进行后续开发。
https://github.com/Rust-for-Linux/linux：Linux内核的Rust支持。
【预期目标】
注意：下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
第一级：NuttX整体rust支持框架包括编译框架，可以加载和执行模块和应用。
第二级：利用Rust重写NuttX中的某个子系统框架，并能正常使用和运行。
第三级：相关工作成果可以提交到Rust或NuttX开源社区并通过评审。
【指导专家】
接口人：秦蔚，[email protected]
小米公司Vela研发团队（含NuttX社区主要代码提交人）
【对选择该赛题的支持】
技术答疑指导：针对NuttX实时操作系统和Vela平台提供业界最专业权威的技术支持和指导、提供小组答疑会和试题技术方案的实现思路指导
技术资料支持：提供相关技术资料和对应索引，以及k210板卡Vela调试和使用环境搭建指导。
线上技术培训：提供线上的Nuttx RTOS总体培训讲解，并对试题相关部分进行针对性讲解。
赛题方向指引：我们希望参赛团队根据自己的理解和思路，完成相关的代码架构设计，我们可以进行代码架构的评估和建议和以及针对NuttX修改思路上的指导。
获奖激励：对于优秀的二等奖以上获得者，提供小米Vela操作系统团队北京和武汉的实习机会，直接参与小米开源操作系统的开发工作，面对面和开源社区大神进行技术交流，相关成果经审核后可进入Nuttx开源社区。
入职礼包：优秀的获奖者入职后可以提供入职礼包（一套基于Vela系统的智能家居产品）。
03
【Proj181】基于Vela平台的POSIX和Wasm的多语言运行时
https://github.com/oscomp/proj181-xiaomi-vela-posix-wasm-runtime
【赛题背景】
WebAssembly（以下简称Wasm）技术对于没有MMU的小型嵌入式操作系统是一个很好的补充，它具备高性能并且让应用和系统之间能够隔离开，Wasm生态目前也在逐步完善中，类似C、C++、Go、Rust、Assembly Script等流行语言都支持编译到Wasm，创建一个统一的多语言运行时具备丰富嵌入式应用开发生态、提升应用开发效率和安全性的意义。
【赛题难度】中等
【功能点】
所有功能点应能在K210板卡上运行并演示。
以Vela平台为基础，使用NuttX作为目标OS，使用WAMR作为Wasm虚拟机
提供NuttX端的bottom half库和WAMR/语言端的upper half库
支持C、C++、Rust和Assembly Script
【参考资料】
https://nuttx.apache.org/docs/latest/
https://github.com/apache/incubator-nuttx/tree/master/boards/risc-v/k210/maix-bit
https://rustwasm.github.io/docs/book/
https://github.com/WebAssembly/wasi-sdk
https://www.assemblyscript.org
https://github.com/bytecodealliance/wasm-micro-runtime
https://nuttx.apache.org
【预期目标】
下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
完整且独立的开发SDK和C/C++/Rust/Assembly Script支持
拓展配套的NuttX/WAMR端支持库
【指导专家】
黄齐
Bytecode Alliance RC / WAMR TSC Member , [email protected]
小米公司Vela研发团队（含NuttX社区主要代码提交人）
【对参赛队提供的支持】
技术答疑指导：NuttX在Wasm支持方面与WAMR在多语言支持方面的现状及改进方向、针对NuttX实时操作系统和Vela平台提供业界最专业权威的技术支持和指导、提供小组答疑会和试题技术方案的实现思路指导。
技术资料支持：提供相关技术资料和对应索引，以及k210板卡Vela调试和使用环境搭建指导。
线上技术培训：提供线上的NuttX RTOS总体培训讲解，并对试题相关部分进行针对性讲解。
赛题方向指引：我们希望参赛团队根据自己的理解和思路，完成相关的代码架构设计，我们可以进行代码架构的评估和建议和以及针对NuttX修改思路上的指导。
获奖激励：对于优秀的二等奖以上获得者，提供小米Vela操作系统团队北京和武汉的实习机会，直接参与小米开源操作系统的开发工作，面对面和开源社区大神进行技术交流，相关成果经审核后可进入NuttX开源社区。
入职礼包：优秀的获奖者入职后可以提供入职礼包（一套基于Vela系统的智能家居产品）。
04
【Proj182】基于NuttX RTOS的符合POSIX规范和SMP系统的高效任务调度器实现
https://github.com/oscomp/proj182-xiaomi-nuttx-smp-scheduler
【赛题背景】
在RTOS领域，SMP多核系统下的任务调度策略是操作系统优化的重要主题，任务调度作为OS中最常发生的几个事件，提升调度系统的效率能够有效地提升系统的整体运行效率。POSIX规范中给出了多核调度器的实现要求。本项目的目标是基于NuttX已有的多核支持，实现一个符合POSIX规范的多核调度器，进一步优化NuttX在SMP系统上的工作效率。
【赛题难度】中-高
【功能点】
所有功能点应能在K210板卡上运行并演示。
1.符合POSIX规范，支持FIFO、RR、Sporadic调度策略。
2.对称式调度器（每个核心维护自己的task list）or 其他更优的无锁实现。
3.适配K210板卡，并考虑多平台的可扩展（ARM、Xtensa）。
【参考资料】
https://nuttx.apache.org/docs/latest/：NuttX的最新文档，可以直接下载并按照要求配置和使用K210板卡。
https://github.com/apache/incubator-nuttx/tree/master/boards/risc-v/k210/maix-bit：NuttX文档中对K210板卡的配置和使用说明。
https://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_08.html：Open Group关于调度策略的指导手册。
https://github.com/apache/incubator-nuttx/tree/master/sched/sched
https://nuttx.apache.org
https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/5_CPU_Scheduling.html：调度器的一些基本知识。
【预期目标】
下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
完成每个cpu core local的调度器，减少当前代码中全局锁的使用。
【指导专家】
黄齐
Bytecode Alliance RC / WAMR TSC Member , [email protected]
小米公司Vela研发团队（含NuttX社区主要代码提交人）
【对参赛队提供的支持】
技术答疑指导：NuttX的内核实现及改进方向、针对NuttX实时操作系统和Vela平台业界最专业权威的技术支持和指导、提供小组答疑会和试题技术方案的实现思路指导
技术资料支持：提供相关技术资料和对应索引，以及k210板卡Vela调试和使用环境搭建指导。
线上技术培训：提供线上的NuttX RTOS总体培训讲解，并对试题相关部分进行针对性讲解。
赛题方向指引：我们希望参赛团队根据自己的理解和思路，完成相关的代码架构设计，我们可以进行代码架构的评估和建议和以及针对NuttX修改思路上的指导。
获奖激励：对于优秀的二等奖以上获得者，提供小米Vela操作系统团队北京和武汉的实习机会，直接参与小米开源操作系统的开发工作，面对面和开源社区大神进行技术交流，相关成果经审核后可进入NuttX开源社区。
入职礼包：优秀的获奖者入职后可以提供入职礼包（一套基于Vela系统的智能家居产品）。
第二部分：TEE团队赛题
05
【Proj183】基于zCore的TEEOS
https://github.com/oscomp/proj183-xiaomi-zcore-teeos
【赛题背景】
Android 系统是目前应用最广泛的手机操作系统，拥有开放的生态环境，由此它的安全性也备受大家关注。TEE（Trusted Execution Environment）是一种基于硬件隔离的解决方案，独立于 Android 系统之外的可信执行环境，与可信执行环境（TEE）相对的是运行普通操作系统和应用程序的 REE（Rich Execution Environment）。相比于运行在 REE 的 Android 系统，TEE 拥有更高的权限，运行于 Android 无法访问的独立的执行内存中，应用程序可以把关键处理和敏感数据放在 TEE 中执行或加密存储，这样即便是有攻击者获得了 Android 系统的 Root 权限，也无法进一步窃取或攻击 TEE 中的数据。
目前Android系统大部分的硬件平台是ARM soc，TEEOS基本上都是C/C++实现的，本赛题目标是以zCore（rust实现的zircon微内核）为基础，构建运行在ARM trustzone 上的TEEOS，用rust实现Global platform标准API，在REE侧实现对应的client API。在TEEOS实现之后，可以用rust写一个测试CA（client application）和TA（trust application）进行验证。
【赛题难度】
第一阶段：难度中等
第二阶段：难度较高
【预期目标】
硬件平台可以选用树莓派，第一阶段是基础，第二阶段是挑战。
第一阶段：
在ARM secure world 移植zCore，涉及bootloader、ATF等改动。
实现REE/TEE的IPC，Android侧和zCore侧需要对应的driver，通过shared memory实现IPC。
通过IPC实现Android侧执行TEE侧的shell。
第二阶段：
zCore上面搭建TEE框架，支持Global platform API，包括TA management，secure storage，Cryptographic algorithm等。
完善调试机制，可以分析TEE crashdump。
用rust实现一个测试CA和TA，验证Global platform API。
【指导专家】
第三部分：Mina团队赛题
06
【Proj184】 Heap 异常检测工具
https://github.com/oscomp/proj184-xiaomi-anormal-heap-checker
【赛题背景】
【赛题难度】中等
【指导专家】
【说明】
建议使用c/c++/rust语言,运行环境可选择任一linux发行版
低性能开销、低内存消耗，稳定性高
可运行在arm/arm64/x86架构上
【参考文档】
参考linux kfence :
https://docs.kernel.org/dev-tools/kfence.html
linux kernel:https://kernel.org/
【License】
GPLv2 (https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)
【预期目标】
下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
第一级：实现UseAfterFree、HeapBufferOverflow、DoubleFree的捕获，可参考linux 内核里kfence的实现，捕获到异常信息尽量准确， 消耗较少的资源，能够在开发或是release版本里一直使用。异常信息包含的内容参考特征4.
第二级：实现在适当的时机触发对HeapBufferleak检测，查阅相关资料，尽量准确的总结内存泄露特征，对每种特征加权，权值大于某个阈值意味着该内存泄露的概率较高，对泄露概率较高的内存输出预警信息，预警信息包含的内容参考特征4。特征及其权值最好能够简单的配置，可由应用场景来进行不同的组合。
第三级：输出设计文档与参考code。
07
【Proj185】宿主机内两个或者多个客户系统间的通讯
https://github.com/oscomp/proj185-xiaomi-guest-vm-comm-in-host
【赛题背景】
伴随着云技术的发展，Open vSwitch能够做到系统间数据包高质量转发，包括宿主机内多客户系统间的宿主机内转发，能满足大多数应用场景。但是这种技术基于网络协议栈，在内存共享、零拷贝、实时性等方面有着缺陷，这又是日益兴起的AIOT领域的强烈需求。
本项目目标是实现客户系统间实时的内存共享方式的通信机制。
主要手段：
1 通过内存虚拟化的stage mmu实现不同客户系统共享内存来实现大数据的传递。
2 通过客户机、宿主机协同，软硬件一体设计提高实时性。
3 通过定制VCPU、中断、客户机内存（GPA）为上述实现提供基础。
客户机虚拟硬件：
扩展出一段GPA内存作为接受共享内存的区间。
扩展出一个专用VCPU。客户机内核要保证使用共享内存的线程绑定在这个扩展的CPU上，且属于RT Sched Class。且Host保证这个VCPU对应线程属于RT Sched Class。
扩展一个中断用来响应共享内存事件，该中断最好由扩展VCPU响应。
工作场景：
但客户机发起传输时，向KVM下发对端客户机及共享内存参数，KVM解析出需要共享的内存HPA，再将机器内存映射到对端客户机的stage2 MMU上。然后触发对端客户机扩展VCPU的特定中断，该中断handler唤醒客户机的处理线程。
本项目建议采用Linux KVM路线，主从系统皆为Linux，上层VMM可以自由选择，如QEMU、CrosVM均可。
参赛者也可采用type1路线，自主选择hypervisor，宿主系统仍需皆为Linux。
硬件架构建议采用arm64、x86-64，推荐的开发平台有rk3588、树莓派4。
【赛题难度】中-高
【指导专家】
【预期目标】
本项目有3个阶段目标。
第一阶段：基础层次
有完整的架构设计、基本的协议设计。
实现项目描述的功能。
第二阶段：完善层次
1.有改进的架构设计，比如借助virtio、host机制改进VCPU中断机制；有基本协议设计、比如事务的定义支持同时或者依次分发给多个客户机；有安全性设计，如使用完毕及时隔断客户机对机器内存的映射。
2. 基于完善的架构设计完成项目描述功能、且实现全部或者部分协议及安全性保护。
第三阶段：挑战层次
完成以下真实场景：不停读取摄像头数据，然后依次交给客户机1、客户机2处理，最后显示出来。
2.摄像头操作、图像显示放在host、vmm、还是客户机中，不限制。
3. 对于每一帧的处理算法不限，只需不少于5ms，若kvm方案实现基于前后端使用GPU，type1方案基于直通使用GPU，都是加分项。
08
【Proj186】资源受限下OTA静默升级系统
https://github.com/oscomp/proj186-xiaomi-OTA-using-small-resources
【赛题背景】
在存储资源受限的硬件平台上，实现操作系统的静默升级，在做到用户无感知的同时，充分利用到平台的存储资源。linux系统中常用的基于AB分区的OTA升级系统可做到系统升级用户无感知，但总有一半存储空间未加以利用；而Non-AB系统虽能完全利用存储空间，但需要设备进入recovery模式，用户在此期间无法使用设备，另外，virtual AB升级对AB升级进行了一定程度的改变，需要升级系统的时候，将新系统的数据和现在的数据进行对比校验，将差异部分写入另外一个分区，而不是系统分区，之后，利用新数据启动系统，如果系统顺利启动，那么就将差异数据写入到系统分区，启动失败则抛弃差异数据，用原来系统分区的数据启动。Virtual AB机制既有A/B分区的可靠性优点，也无需像A/B分区那样占据大量的额外空间. 有没有一种机制, 比Virtual AB还能有更少占用系统分区存储，却能达到用户无感知的升级方案呢？请为资源受限的设备，提供OTA静默升级，设计实现一套新方案。
【赛题难度】中等
【指导专家】
【说明】
使用 c / c++ / rust 语言，推荐使用rust实现。
系统用户无感知，即升级过程不干扰用户的正常使用，这项可通过特征5保证。
存储空间最大程度的加以利用，增加用户可用空间大小，降低产品成本，提升用户体验
满足ARM aarch64 / riscv 架构支持。
升级过程中，控制各项系统资源占用，例如处理器、内存、带宽等需要给予合理阈值的限制。
在满足特征5的情况下，尽量减少系统升级总体耗时，以减少设备发热、耗电。
升级包应当签名，升级程序须验证升级包的合法性。
升级包应当加密，升级程序须在验证升级包的合法性后再解密出真实数据。
处理升级失败的情况，如签名错误、解密失败，电源中断、网络掉线等等异常情况。
处理版本的回退，如禁止高版本降级到低版本。
升级失败汇总处理，如出错则回退到旧版本。
支持定期查询、自动更新和用户手动查询、更新两种模式。
【参考文档】
https://source.android.google.cn/devices/tech/ota/dynamic_partitions/implement
https://source.android.google.cn/devices/tech/ota/virtual_ab/implement-patches?hl=en
virtual AB:
https://source.android.com/devices/tech/ota/virtual_ab/
https://doc.rust-lang.org/book/
【License】
GPLv2
Apache 2.0
【预期目标】
下面的内容是建议内容，不要求必须全部完成。选择本项目的同学也可与导师联系，提出自己的新想法，如导师认可，可加入预期目标。
第一级：编写升级包生成工具，包括但不限于打包、分析、签名、验签、加密、解密、压缩、解压缩等。
第二级：搭建后台升级服务器，实际可以用本地局域网环境模拟。
第三级：系统联网后，在更新界面可查询到OTA服务器推送的新版本，包括版本号、包大小等信息。
第四级：系统联网后，可在后台按照设定好的升级周期自动完成查询、更新操作，无需用户介入。
第五级：实现比VirtualAB更节省空间的静默升级方案, 可以引入super分区，采用dm-snapshot等技术来进行升级。
大赛指定竞赛网站：https://os.educg.net/
大赛邮箱：[email protected]