吹响开源集结号—“点亮”暑期2020

openEuler 社区 | 2020-05-07

开源软件供应链点亮计划-暑期2020” 活动是什么?

“开源软件供应链点亮计划-暑期2020”(以下简称暑期2020)是由 中科院软件所openEuler 社区 共同举办的一项面向高校学生的暑期活动,旨在鼓励学生积极参与开源软件的开发维护,促进国内优秀开源软件社区的蓬勃发展。

中科院软件所openEuler 社区 联合国内外开源社区,对开源软件的开发与维护提供多种难度的任务,在 2020 年 6 月 1 日向全国高校学生开放报名。学生可自主选择感兴趣的项目进行申请,在中选后获得该软件资深维护者(社区导师)亲自指导。根据项目的难易程度和完成情况,参与者还将获得“开源软件供应链点亮计划-暑期2020”活动奖金和奖杯

如何参与 “开源软件供应链点亮计划-暑期2020” ?

活动主要由学生、社区、导师组成:

  • 学生:学生自由选择项目,与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下,按计划完成开发工作,并将成果贡献给社区。社区评估学生的项目完成度,主办方根据评估结果发放奖金给学生。
  • 社区:社区提供项目列表和描述,并安排项目对应的社区导师。社区导师与申请者沟通方案,并从申请者中选中一位承接项目。在为期三个月的开发周期中,社区导师将负责指导学生进行对应项目的开发。
  • 导师:社区针对每一个项目指定一个社区导师,通常为相关开源软件的维护者。社区导师将与学生一起制定合适的开发计划和方案,指导学生按计划完成开发。

心动不如行动,快来加入我们吧!

学生报名:

  • 年满18周岁的在校学生。具有有效的学生证身份证
  • 2020年6月1日正式开启,请关注官方网站和公众号_ISCAS_ISRC_。

如何参与到 openEuler 社区任务

参与 openEuler 的任务必须先签署贡献者许可协议(CLA)

  1. 注册 Gitee.com 账号。
  2. 贡献者许可协议 页面的底部选择 个人独立贡献者 签署。

浏览选择感兴趣的任务和社区导师沟通

在 暑期2020 任务列表 页面或本页最后 openEuler 社区任务列表 浏览选择感兴趣的任务进入到详细页面。

  1. 通过 Issue 和任务导师沟通。 直接在 Gitee Issue 中留言,针对任务提出问题和任务导师在 Issue 中进行讨论。
  2. 在任务说明中有导师的邮箱,通过邮件针对任务和导师详细沟通。邮件中请首先介绍自己的情况、自己感兴趣任务的链接,对于不理解的地方请详细描述。
  3. 在订阅 Community 邮件列表订阅页面 订阅 Community 邮件列表,订阅成功后向 community@openeuler.org 发送邮件针对感兴趣的任务进行咨询,编写邮件的建议同 2. 。

openEuler 社区任务列表(持续更新中)

No.1 - 为 openEuler 添加 Xfce 桌面环境并能够运行在树莓派 4B 上

描述 树莓派(英语:Raspberry Pi)是基于 Linux 的单片机电脑,目的是以低价硬件及自由软件促进学校的基本计算机科学教育。openEuler 树莓派版本目前没有桌面环境。本项目的目标是为树莓派添加桌面支持,即适配桌面环境 Xfce 到 openEuler 树莓派 4B。

难度

导师 @woqidaideshi

联系方式 yafen@iscas.ac.cn

任务链接 https://gitee.com/openeuler/marketing/issues/I1H8G3

No.2 - 精简 openEuler 的树莓派 4B 镜像体积小于 500 MiB

描述 树莓派(英语:Raspberry Pi)是基于 Linux 的单片机电脑,目的是以低价硬件及自由软件促进学校的基本计算机科学教育。树莓派需要刷写文件系统镜像来实现启动,镜像文件常常都较大,不利于快速分发和安装。本项目目标是为制作压缩前小于 500 MiB 的 openEuler 树莓派 4B 镜像,并能够通过 DNF 或 YUM等安装软件源中更多的软件进来。镜像尽可能小。

难度

导师 @woqidaideshi

联系方式 yafen@iscas.ac.cn

任务链接 https://gitee.com/openeuler/marketing/issues/I1H8H9

No.3 - 为 openEuler 树莓派 4B 镜像提供 UEFI 启动支持

描述 树莓派(英语:Raspberry Pi)是基于 Linux 的单片机电脑,目的是以低价硬件及自由软件促进学校的基本计算机科学教育。为了降低成本,树莓派省去了传统计算机用来存储引导加载程序的板载存储器(BIOS), 直接把引导程序放在了SD卡中。目前树莓派 Pi 4 引入了 UEFI,不过目前处于 EXPERIMENTAL 状态。本项目目标是为树莓派引入 UEFI Firmware 来支持 UEFI 启动 openEuler 树莓派 4B。

难度

导师 @woqidaideshi

联系方式 yafen@iscas.ac.cn

任务链接 https://gitee.com/openeuler/marketing/issues/I1H8HV

No.4 - 在 openEuler aarch64 架构上完成 Tensorflow 基于公开数据集完成 mnist 训练过程

描述 没有软件工程师不知道 Hello world,也没有 AI 工程师不知道 mnist 。OpenEuler 上对 AI 的支持也正如火如荼进行,为了让大家熟悉在 openEuler 上 AI 的软件栈和开发流程,请从源代码出发构建 Tensorflow 的 aarch64 架构安装包(包括 pip 和 yum ),用这些安装包基于公开的数据集完成 mnist 的训练过程。

难度

导师 @sinever

联系方式 sinever@126.com

No.5 - 在 openEuler aarch64 架构上完成 PyTorch 基于公开数据集完成 mnist 训练过程

描述 没有软件工程师不知道 Hello world,也没有 AI 工程师不知道 mnist 。OpenEuler 上对 AI 的支持也正如火如荼进行,为了让大家熟悉在 openEuler 上 AI 的软件栈和开发流程,请从源代码出发构建 PyTorch 的 aarch64 架构安装包(包括 pip 和 yum ),用这些安装包基于公开的数据集完成 mnist 的训练过程。

难度

导师 @sinever

联系方式 sinever@126.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HR9C

No.6 - 虚拟化场景下的类似 top 点调测工具 virttop

描述 云场景,性能类问题无法快速定位定界,缺少定位手段。例如CPU性能不足,网络性能抖动等常见问题定位周期长,定位手段少。CPU超分场景经常出现虚拟机的 vcpu争抢,需要提供vcpu使用监控手段,期望能够提供一套类似top的实时监测工具。

难度

导师

  • @zhanghailiang_lucky
  • @yorifang

联系方式

  • zhang.zhanghaliang@huawei.com
  • fangying1@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HVM7

No.7 - 构建可运行 iSulad 点容器镜像,并推送到 Docker Hub 镜像仓库

描述 当前 Docker Hub 等镜像仓库中无 iSulad 镜像,要求制作能够运行 iSulad 的容器镜像,并推送到 Docker Hub 上,能够使用 Docker、iSulad 下载该镜像,并能够启动 iSulad 。

难度

导师 @lifeng2221dd1

联系方式 lifeng68@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HVZF

No.8 - C 语言 JSON 解析转换代码生成框架

描述 当前 iSulad 项目中,存在大量的json相关的操作(C结构体转换为JSON字符串,JSON字符串转换为C结构体)。由于C语言没有反射机制,导致无法动态解析JSON字符串。因此,需要一个生成解析和转换代码的框架。而且该框架可以支持多种json解析库,例如c-json,yajl等等。

难度

导师 @haozi007

联系方式 liuhao27@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HWB3

No.9 - iSula 相关项目支持编译 Debian 包

描述 当前 iSula 相关项目,只支持 rpm 编译方式(提供了spec文件)。但是 Debian 相关的系统上面需要源码编译,所以存在编译不方便的问题。因此,需要提供 Debian 打包的支持。

难度 简单

导师 @haozi007

联系方式 liuhao27@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HWDZ

No.10 - iSula 项目内存池设计与实现

描述 当前 iSula 相关项目无内存池设计,程序在堆上频繁分配和释放内存,容易造成系统出现大量内存碎片,同时也降低了内存的利用率,也造成了 iSulad 性能的损失,因此,iSulad 需要设计一个高效高性能且可应对高并发的内存池设计。

难度

导师 @jingwoo

联系方式 wujing50@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HX3G

No.11 - iSula 项目线程池设计与实现

描述 当前 iSula 相关项目无线程池设计,程序存在频繁创建和销毁线程的场景,CPU 资源开销大, 效率也相对低下,因此,iSulad 需要设计一个高性能的线程池,能支持自动扩容与收缩的动态资源分配。

难度

导师 @jingwoo

联系方式 wujing50@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HX5Y

No.12 - iSula-kits 支持在多个 OS 发型版上运行

描述 iSula-kits 为 iSula 容器全栈的工具集,包括镜像构建工具、容器升级工具等。当前 iSula-kits 只支持在 openEuler OS 上运行,我们需要将 iSula-kits 工具集稳定可靠运行在其他主流的发行版OS上。推荐优先完成:CentOS,Ubuntu,openSuse,Fedora,Debian 的最新版本。

难度

导师

联系方式

  • leizhongkai@huawei.com
  • zhangsong34@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HXE7

No. 13 - iSula 容器镜像构建工具支持多存储驱动

描述 iSula-kits 项目中的容器镜像构建工具 isula-build 目前底层驱动只支持 Overlay2。在一些特性场景下块设备具有独特的性能优势,例如:大文件读写等场景。我们需要增加一种后端的存储驱动:devicemapper,并且可以通过配置来选择驱动。

难度

导师 @jingxiaolu

联系方式 jingxiaolu@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HXS9

No. 14 - openEuler 集成 Harbor 项目

描述 Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器,可以用来构建企业内部的Docker镜像仓库。容器镜像仓库是云原生中的重要组成部分,因此我们希望参与者能够提供harbor在openEuler上的标准发布软件包,并在社区的基础上能够便捷、快速的让使用者使用harbor组件

难度

导师 @caihaomin

联系方式 caihaomin@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HXBE

No.15 - 改进 openEuler-Advisor 来支持 openEuler 快速滚动升级

描述 绝大多数开源软件被集成到 openEuler 中以后,并不需要做额外的修改。比如当前 openEuler 中有 1276 个软件可以直接基于上游社区源码构建。 我们希望改进 openEuler-Advisor,在识别到这类软件有升级以后,可以自动化的完成软件版本更新,并提交 PR。

难度

导师 @Shinwell_Hu

联系方式 huxinwei@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HXMV

No.16 - 为 ARM 平台优化开源软件的 CRC 实现

描述 CRC 可以用来检测数据的完整性,在存储、压缩解压缩、通信等领域是被广泛使用的算法,openEuler中就有大量软件使用。鲲鹏平台(兼容ARM v8.1)中全面支持了CRC加速指令,相对软件查表实现,性能有30倍的差异。但是加速指令并没有在软件实现中得到普及。

难度

导师 @Shinwell_Hu

联系方式 huxinwei@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HYCD

No.17 - 库函数行为收集器

描述

访问控制针对的是应用、被访问的对象以及访问模式。但是,为了做好访问控制,对于一个程序(无论是二进制的还是有源码的),让开发者去逐个搜罗所有可能的访问对象也是很头疼的事,尤其是隐含在所使用的库函数中的访问对象,甚至是隐藏在深层嵌套的函数中的访问对象。【这里不提strace、ltrace类工具,因为那是需要把应用运行起来才能去收集访问对象的。这里关注的是静态获取访问对象。】

比如,Linux系统中有很多本地的小数据库文件(多是纯文本格式的),C库都提供了相应的函数去使用这些数据库。下面简单列出几组: | 文件 | C函数 | 访问模式 | |—|—|—| |/etc/passwd|getpwent()|r/w| |/etc/group|getgrent()|r/w| |/etc/shadow|getspnam()|r/w| |/etc/services|getservent()|r/w| |/etc/fstab|getmntent()|r/w| |/etc/hosts|gethostent()|r/w|

如果应用调用了以上函数,就可以确定此应用会操作对应的文件对象。当然,C库中也有并非针对类似数据库对象的函数。

对C库的所有函数构造一个{func, file, access_mode}的映射表(可称为 函数级访问映射表 ),就可以帮助开发者挖掘出隐含的访问对象。C库的历史很久了,其中所含函数的行为也基本稳定,相应地,这个函数级访问映射表也应该是稳定的。

很多其它库与C库类似,可以把这种方法推广到其它库上。为这些库建立一个映射表后,可以自动获取应用中隐含的访问对象(至少是部分的),其余的部分可以让开发者自己去补充(开发者对此应该非常了解)。

进一步说,对于一个C源程序,找出其中所含的函数(可能是深层调用的),再借助上述映射表,就可以构建出{app, file, access_mode}这样的 应用级访问映射表 ,作为为此应用制定访问控制策略的输入。

本任务的目的就是完成一个工具,实现对这种应用级映射表的自动构建。

具体步骤包括: 1,收集【先只针对C库】 : 收集C库中的所有函数,找出它们要访问或者引用的文件(具有磁盘文件inode的各类对象),形成一个{func, file, access_mode}的映射表; 2,扫描:扫描给定app的源码(C),找出步骤1中可以识别的函数; 3,汇总:基于扫描结果,形成该app的访问映射表{app, file, access_mode}集合。 这个集合不是app的所有访问范围,只是隐含在库函数中的访问范围。【其它明确通过open类函数使用的文件对象可由开发者单独列出】

后续工作: 扩展所考察的库范围,构造一个具有此功能的“专家库”。

难度

导师 mailofzxf

联系方式 mailofzxf@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I06J

No. 18 - SVA (Share Virtual Address)引擎

标题 No. 18 - SVA (Share Virtual Address)引擎

任务描述

现代的 Linux 操作系统中的用户态程序均基于 Virtual Address。不用用户态程序的 Virtual Address 相互独立,即用户态程序独占各自的 Virtual Address Space。当两个或者多个进程进行进程间通信时,通过基于 share memory 的 IPC 机制可以将不同 Virtual Address Space 中的 Virtual Address 指向相同的 physical memory。但 App1 中 “共享内存” 所占用的 Virtual Address 和 App2 中 “共享内存” 所占用 的 Virtual Address 可能并不相同。试想有一个 ‘SVA engine’,通过 ‘SVA engine’ 提供的操作接口,将多个 APP 挂载到 ‘SVA engine’ 上。挂载到 ‘SVA engine’ 上同一个 ‘channel’ 的 APP 将共享 Virtual Address Space 中的一段或者多段虚拟地址。

难度

导师 @liliang_euler

联系方式 liliang6@me.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I1D1

No. 19 - LSCA - Linux 系统调用代理

任务描述 Linux 内核提供了系统调用给用户态程序调用。Linux APP 通过系统调用获取 Linux 内核提供的各项服务。对 APP 而言,使用到的系统调用可能只是 Linux 内核提供的全部系统调用集合的一个子集。

基于如下考虑: > 对一个标准 APP 而言,其一般通过 glibc 提供的对系统调用的封装进行系统调用。那么 LSCA(Linux System Call Agent) > 期望取代 glibc 完成的功能,针对系统调用,进行自定义的封装。

LSCA 首先接管 APP 的系统调用请求,然后根据配置,完成:

  • log 到日志(依据配置,可选)
  • 完成真正的 System Call(真正的系统调用不能够 通过和 Linux 内核进行交互来完成,特征是,由 Linux 内核提供的系统调用服务需要切换处理器运行模式,而此处提供系统调用服务的是 LSCA daemon 服务,不需要切换处理器运行模式)。

难度

导师 @liliang_euler

联系方式 liliang6@me.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I1JR

No. 20 - LUTF - Linux Userspace Task Framework

任务描述 标准的 Linux 的用户态任务(基本粒度为 Thread)通常由 Linux 内核进行管理和调度。LUTF 是一套非标准的任务框架。

LUTF要完成:

  • 任务的定义与抽象,典型的,一个任务可以是一个C语言函数
  • 提供任务的管理接口,提供任务的创建,管理等功能;
  • 进行任务的调度;

约束: > 纯 Linux 用户态实现; > 同时支持的任务数量不少于一百万; > 任务的调度支持 FIFO; > 基于 setjmp 和 longjmp 实现任务切换; > 基于 signal 实现中断;

难度

导师 @liliang_euler

联系方式 liliang6@me.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I1RK

No.21 - 为openEuler - RISC-V 添加grub的引导启动方式

描述 RISC-V 是一个开源指令集(ISA instruction set architecture ),openEuler 对于此架构正在进行探索性的支持,成立了 RISC-V SIG 组;Grub是主流linux发行版都采用的引导方式。在启动方式上,与openEuler 发行版镜像所采用的grub2 引导启动不同的是,openEuler for RISC-V 采用的是openSBI + kernel 直接启动的方式。目前openEuler的grub 版本是2.02,在grub 2.04 版本中,新增了对于RISC-V 架构的支持;因此,可以为 openEuler for RISC-V 添加grub 的引导启动的方式,使其能够接近openEuler发行版的启动形式。

难度

导师 @whoisxxx

联系方式 zhangxuzhou4@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I1TS

No.22 - 在 openEuler aarch64 架构上完成 mlpack 基于公开数据集完成 mnist 训练过程

任务描述 没有软件工程师不知道 Hello world,也没有 AI 工程师不知道 mnist。OpenEuler 上对AI 的支持也正如火如荼,为了让大家熟悉在 openEuler 上 AI 的软件栈和开发流程,现在请从源代码出发构建 mlpack 的安装包(yum),用自己构建的安装包基于公开的数据集完成 mnist 的训练过程。

难度

导师 @sinever

联系方式 sinever@126.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I281

No.23 - 在 openEuler aarch64 架构上完成 Hadoop WordCount 统计过程

任务描述 没有软件工程师不知道Hello world,也没有大数据工程师不知道wordcount。OpenEuler上对bigdata的支持也正如火如荼,为了让大家熟悉在openEuler上的bigdata的软件栈和开发流程,现在请从源代码出发构建hadoop的安装包(jar和yum),用自己构建的安装包完成wordcount的统计过程。

难度

导师 @sinever

联系方式 sinever@126.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I290

No. 24 - 在 openEuler aarch64 架构上完成 Spark WordCount 统计过程

任务描述 没有软件工程师不知道Hello world,也没有大数据工程师不知道wordcount。OpenEuler上对bigdata的支持也正如火如荼,为了让大家熟悉在openEuler上的bigdata的软件栈和开发流程,现在请从源代码出发构建spark的安装包(jar和yum),用自己构建的安装包基于公开的数据集完成wordcount的训练过程。

难度

导师 @sinever

联系方式 sinever@126.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I29G

任务描述 没有软件工程师不知道Hello world,也没有大数据工程师不知道wordcount。OpenEuler上对bigdata的支持也正如火如荼,为了让大家熟悉在openEuler上的bigdata的软件栈和开发流程,现在请从源代码出发构建 Flink 的安装包(jar和yum),用自己构建的安装包完成wordcount的统计过程。

难度

导师 @sinever

联系方式 sinever@126.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I2A0

No.26 - 在openEuler 版本上各个版本间进行包差异比较

描述 linux操作系统由众多开源软件包组成,为了更好对于各个操作系统版本间的软件包进行对比分析,需要获取操作系统自带软件包信息,以及对不同版本间操作系统软件包进行对比分析,分析内容包括软件包,软件包版本,软件包安装后的文件结构,软件包携带的服务、软件包携带的配置信息等。

难度

导师 @jimmy_hero

联系方式 huming15@163.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I49K

No.27 - 开发工具判断同一个软件在openEuler 不同系统间依赖的软件、接口、参数是否发生变化

描述 不同操作系统的软件包组成不完全一致,对应用程序而言是灾难性的,存在大量工作在评估软件之间是否兼容性,希望能够有一个软件,对软件的依赖在不同系统下进行评估,确认不同系统对应用的影响,提高跨系统移植的效率。

导师 @jimmy_hero

联系方式 huming15@163.com

产出标准

  • https://gitee.com/openeuler/oec-application 项目提交相关可以在基于如下环境运行的工具,
  • 将某个程序作为输入, 两个操作系统的信息作为输入,工具能够根据输入的信息,提供评估结果。
  • 操作系统版本:openEuler 20.03 LTS
  • 架构:aarch64

任务链接 https://gitee.com/openeuler/marketing/issues/I1I4BT

No.28 - 网络可视化工具

描述 BCC/BPFTrace/eBPF是目前比较活跃的内核窥探技术,目的是通过此类技术完成内核网络的窥探,实现一些可以可以在生产环境部署的窥探工具。相关的工具包括但不限于:

  • 窥探TCP流类型,判断应用的流特点,可以大体划分成时延敏感性、生命周期短、数据流大等几种类型;
  • 窥探TCP重传、RTT、队列深度、内存占用的情况,评估网络质量;
  • 窥探协议栈、驱动,通过报文染色方式,完成E2E网络定界;
  • 实现一个协议栈function trace工具,能够基于流trace内核协议栈函数调用栈。

上述工具要充分考虑对现有协议栈性能的影响,最好能够支持在生产环境部署。

难度

导师 @MrRlu

联系方式 newlife_lala@163.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I550

No.29 - 对openEuler社区发布包osc和obs-build进行加固测试

描述 openEuler 社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师

  • @charlie_li
  • @lemon-higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I5WZ

No.30 - 基于 openEuler 的 4.19 内核主线 virtiofs 并完成构建和基础使用

描述 virtio-fs是使用FUSE协议在host和guest之间通信,实现在不同guest之间共享同一个host目录树结构,拥有较好的性能和跟本地文件系统(如ext4)一样的语义。

难度 简单

导师 volcanodragon

联系方式 liuzhiqiang@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I62G

No.31 -No.31 - Linux 内核 Crash 问题自动定位工具

描述 Linux 内核异常 Crash,常需要人工进行定位分析,比如分析反汇编,分析函数栈,分析寄存器等信息。期望根据已有的 Crash 信息,能够通过工具自动化解析足够多有用信息,以及尽量能够定位出问题

难度

导师 @yeyunfeng-dev

联系方式 yeyunfeng@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I632

No.32 - 系统资源负载预测框架

描述 为了实现对系统资源的及时调度,A-Tune需要对系统各维度资源进行相对准确的预测,从而能够在运行时进行动态调度,满足性能和功耗诉求。

难度

导师 @xiezhipeng1

联系方式 xiezhipeng1@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I64J

No.33 - 基于 Posix 接口的协程框架

描述 对于大部分应用程序,实际并不关心实际的运行实体是什么。基于linux kernel的线程调度机制相较于协程占用资源多,上下文切换时间长。当前行业内的解决方案主要是语言级别的协程调度方案,典型的如go routine。本课题的目标是基于glibc的posix接口编程,提供用户无感知的协程调度框架,解决提升存量软件性能。 具体包含: 目标一:pthread相关库的协程化,包含线程管理已经基于线程的条件变量,锁等接口。 目标二:基于目标一,实现网络编程相关接口的协程化。 目标三:全量的posix接口协程化配合。

glibc源码: https://gitee.com/src-openeuler/glibc

难度

导师 @liqingqing_1229

联系方式 liqingqing3@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I66U

No.34 - 对 openEuler 社区发布包 keepalived 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。

具体实施策略如下:

  • 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面
  • 进行相应的测试设计活动,如功能类/性能类/可靠性类等
  • 根据测试设计编写相应的测试代码和调试
  • 提交PR到码云对应仓库
  • maintainer评审合入

难度

导师

  • @Charlie_Li
  • @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6CG

No.35 - 对 openEuler 社区发布包 kmod-kvdo 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师

  • @Charlie_Li
  • @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6CY

No.36 - 对 openEuler 社区发布包 OpenVPN 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师

  • @Charlie_Li
  • @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6D6

No.37 - 对 openEuler 社区发布包 lrzsz 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6EO

No.38 - 对openEuler社区发布包ipvsadm进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6F2

No.39 - 对 openEuler 社区发布包 MongoDB 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6GM

No.40 - 对 openEuler 社区发布包 Redis 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6GW

No.41 - 对 openEuler 社区发布包 sssd 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6IK

No.42 - 对 openEuler 社区发布包 MySQL 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6IN

No.43 - 对 openEuler 社区发布包 rpcbind 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6JE

No.44 - 对 openEuler 社区发布包 haproxy 进行加固测试

描述 openEuler社区作为一个集成社区,发布了上千个软件包;为更好地保障各软件包提供的能力能够满足用户使用场景,除依赖原生上游社区的测试能力外,还需要进行更深层更广的测试活动。本任务从系统影响程度和用户使用场景角度出发,选取关键软件包进行测试加强活动。 具体实施策略如下: - 分析软件包提供的功能/具体用户使用场景/发布命令及参数/提供服务/包使用资源消耗等方面 - 进行相应的测试设计活动,如功能类/性能类/可靠性类等 - 根据测试设计编写相应的测试代码和调试 - 提交PR到码云对应仓库 - maintainer评审合入

难度

导师 - @Charlie_Li - @lemon.higgins

联系方式

  • liyongqiang329@163.com
  • lemon.higgins@aliyun.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I6JI

No.45 - 移植 libapparmor 到 openEuler 社区

描述 openEuler社区作为一个集成社区,发布了上千个软件包;上游社区存在多种Linux LSM安全机制,主流包括SELinux、APParmor、SMACK、Tomoyo等,当前openEuler默认使用SELinux安全机制,同时内核也支持APParmor,为满足社区不同的应用场景,在openEuler上也支持apparmor机制

具体实施策略如下: 1、分析上游apparmor上游社区提供的软件包https://gitlab.com/apparmor/apparmor/-/wikis/home 2、将上层软件包移植到openEuler上并进行验证 3、提供移植部署相关的文档材料 4、提交PR到码云对应仓库https://gitee.com/src-openeuler/apparmor 5、maintainer评审合入

难度

导师 - @zhujianwei001 - @mailofzxf

联系方式 zhujianwei7@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I77C

No.46 - SELinux 策略应用指导

描述 当前openEuler社区主要提供了SELinux机制来保证系统的安全性,但SELinux策略规则应用复杂,这也极大的阻碍了该机制在生产环境中的应用。

具体实施策略如下: 1、熟悉SELinux基本使用命令,完善SELinux在openEuler中的使用指导。 2、分析openEuler系统中现有的SELinux规则 3、提供SELinux策略相关问题的排查指导 4、提供新建SELinux策略模块的标准步骤 5、maintainer评审合入

难度

导师 - @zhujianwei001 - @mailofzxf

联系方式 zhujianwei7@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I7H3

No.47 - 开发 openEuler bootstrap 工具

描述
借鉴 Linux From Scratch 和 crosstool-ng,开发一套自动化构建工具,该工具支持利用src.rpm源代码,从零构建 openEuler 。

一个可能的建议是,利用crosstool-ng工具,从openEuler x86_64构建 i686版本的二进制rpm。

目标

  • 开发一套自动化构建的工具。
  • 支持native和cross两种构建方式,支持新架构如i686的构建。
  • 该工具可以交叉构建一个新架构i686的rootfs,该rootfs是由200-300+软件包的rpms组成。
  • 基于这些rpms,可以在koji或obs上继续构建其他上层软件包。最终构建出openEuler所有支持的软件。

思路提示 1. 借鉴LFS,从零构建。 2. 利用crosstool-ng a、增加特性,使用crosstool,可以直接构建rpm b、增加对其他基础软件支持,如krb5、openssh、bash等 c、编译的结果以目标架构的rpm呈现,如bash.i686。

难度

导师 overweight

联系方式 hexiaowen@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HAXJ

No. 48 - openEuler aarch64架构上软件包优化和集成

描述 为了使aarch64平台的用户能够使用上更快的openEuler,我们需要对基础库、加速库进行优化,目前鲲鹏计算已开源一系列基于aarch64的优化,也有很多加速库在上游社区完成了aarch64优化,但这些软件优化尚未集成到openEuler OS中。

这些软件包括但不限于:glibc、snappy、zstd、gzip、isa-l、hyperscan等。

我们需要完成3个工作: 1. 添加打包。 至少完成 isa-l、x265、hyperscan 等3个软件包的添加,在https://gitee.com/src-openeuler新建仓库并增加打包源代码。 2. aarch64优化集成。 将鲲鹏优化的集成到已添加的欧拉的发布包中,至少完成glibc、snappy、isa-l、x265、hyperscan、zstd等6个优化的集成,代码合入到https://gitee.com/src-openeuler指定库。 注:优化代码可以从https://github.com/kunpengcompute获取。 3. 博客总结。 完成后,对鲲鹏优化的优化源码进行阅读,总结完成技术博客,同步发布到openEuler博客。

难度

导师

联系方式

  • jiangyikun@huawei.com
  • zhangxuelei4@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HMNS

No.49 - 基于 openEuler 的 ABI 检查工具

标题 No.49 - 基于 openEuler 的 ABI 检查工具

描述 lvc 有一系列abi的导出和分析工具。

借鉴或复用该开源工具,实现一套完整的abi检查工具。 - 该工具能否查询导出与ABI相关的信息(如API接口,头文件数据结构,配置文件,命令行选项等)。 - 该工具提供统一的框架,支持插件式扩展,前期可以支持c/c++的信息导出,后续可增加对python、perl或java等语言的支持。 - 该工具能够支持统一软件多版本二进制或源码间的abi差异对比。 - 该工具支持报告导出功能。 - 该工具易于应用在openEuler后续软件包升级的差异对比,协助开发者、maintainer评估软件升级的影响。

难度

导师 @overweight

联系方式 hexiaowen@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1HQSE

No.50 - 提供 openEuler 满足 openscap 标准的安全配置基线

描述 OpenSCAP项目提供了由开源社区开发的各种加固指南和配置基线,确保您能够选择适合您组织需求的安全策略。当前openEuler通过安全加固工具已经提供了默认的加固内容,但为了兼容国际主流标准,需要基于openSCAP提供openEuler的安全配置基线。

具体实施策略如下: 1、熟悉openSCAP相关标准。 2、修改openSCAP软件包,指定openEuler的安全配置基线。 3、提交相应的代码 4、maintainer评审合入

难度

导师 - @zhujianwei001 - @mailofzxf

联系方式 zhujianwei7@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I7JW

No.51 - optee 移植到 openEuler

标题 No.51 - optee 移植到openEuler

描述 鲲鹏芯片有 TrustZone 支持,optee 是开源的ARM trustzone OS。任务目标是把 optee OS/driver/client 移植到 openEuler 并在鲲鹏硬件平台上运行起来。

难度

导师 @blue0613

联系方式 gaoguijin@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I8IS

No.52 - openEuler 虚拟化调度性能评估工具及方法构建

描述 云场景下,为充分利用物理资源,虚拟机通常存在CPU复用场景。虚拟化平台在此种场景下,既要保障物理资源充分利用,又要保障虚拟化内部业务Qos,这对虚拟化平台调度是一个重要考验。那么如何做好一个虚拟化调度平台,需要我们构建一套虚拟化调度评估方法及体系,当前openEuler社区此方面能力欠缺,需要我们调研引入适配移植业界典型工具及业务场景评估方法。

难度

导师 @KuhnChen18

联系方式 kuhn.chenqun@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1I9XJ

No.53 - 为 openEuler 创建用户轨迹运营看板

描述 openEuler运营看板已经采集了部分数据,展示了基础数据以及基础的统计数据,比如issue个数、总数等,但对单用户个体数据并没有进行展示,无法知道用户喜好及时推送并制定对应用户的的运营措施。

难度

导师 @Zhongjun2

联系方式 jun.zhongjun@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IAOD

No.54 - 对 openEuler 社区发布包 zip/unzip 进行 CRC 加速

描述 zip/unzip使用了CRC32(多项式0xedb88320)来校验数据的正确性。软件使用了常用的查表法来做CRC计算,性能并不理想。在ARMv8.1,提供了CRC32/CRC32C的专用指令:crc32d, crc32w, crc32h, crc32b, crc32cd, crc32cw, crc32ch, crc32cb。分别实现64bit、32bit、16bit和8bit数据的CRC计算。相对于查表法,ARM CRC指令快30倍左右。也就是说,对同一数据做CRC,加速指令耗用时间是查表法的1/30。对于CRC-32和CRC-32C,GCC提供了builtin函数,可以在C代码里直接调用。builtin函数名字就是对应的汇编指令名字前加“”,比如crc32d函数对应crc32d指令。另外,还需添加“-march=armv8.1-a”编译选项。openEuler社区的zip/unzip发布包均没有为ARM平台做过优化。

本任务的目标就是为这两个软件包在ARM上做加速,提高压缩性能。

难度

导师 @colordev

联系方式 colordev@hotmail.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IAWH

No.55 - 自动脱敏网络抓包工具

描述 现有wireshake、tcpdump这类工具存在两类问题

  • 报文payload信息没有脱敏,导致这类工具无法在生产环境使用。
  • 有些抓包工具在大流量情况下会导致crash,无法在生产环境使用。

实现一个脱敏网络抓包工具,要求如下:

  • 可以灵活抓取网络报文,报文内容要具备自动脱敏能力;
  • 可以在生产环境部署,不影响在线业务性能。
  • 支持主流网卡驱动

难度

导师 @MrRlu

联系方式 newlife_lala@163.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IB4N

No.56 - 以 openEuler LTS 为基础生成公有云镜像

描述 公有云上都是以镜像的形式来使用OS系统,制作一个工具来帮助自动化从openEuler的iso或者repo制作出各种公有云的虚拟机镜像,例如华为云,阿里云,AWS,腾讯云等。

难度

导师 myeuler luanjianhai

联系方式 - myeuler@163.com - luanjianhai@163.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1ICCJ

No.57 - 内核数据竞争检测工具

描述 内核数据竞争检测,业界当前可以通过静态测试工具(比如 SVF 和动态测试方法(比如 kcsan 来检测内核竞争,但是静态测试误报较太多,kcsan动态检测出来的很多问题也是无害的,因此本课题目标是把静态测试工具或动态测试工具(SVF和KCSAN,或其他类似的工具)输出的检测信息作为输入,通过精准构造的方式来构造真实竞争,通过内核自运行或者kasan等机制来检测是否是真正的竞争bug。

难度

导师 walkingwalk

联系方式 wubodong@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1ICGN

No.58 - 为 openEuler 提供 PR Preview 功能

描述 openEuler官网采用Hugo框架渲染Markdown成最终的静态文件部署,开发流程中缺少针对Pull Request的渲染结果浏览,本任务的目标是通过kubernetes的CRD+Operator提供多静态网站实例的编译和浏览功能,提高开发和检视流程的易用性。

难度

导师 @TommyLike

联系方式 tommylikehu@gmail.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1ICRB

No.59 - 开源基础设施智能自检自愈系统

描述 随着社区参与者与贡献规模的增加,社区在不断向开源基础设施提出诸多需求。这给基础设施的运维难度和稳定性带来了挑战,我们希望基础设施能更加强健,并具有一定的自检查、自修复能力。

难度

导师 @George.Cao

联系方式 george.cao@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1ICRK

No.60 - everything tool on openEuler

描述

windows下everything工具是非常好用的文件快速检索软件,但是在linux下一直没有对应工具(有一些很有历史的命令,做不到快速检索);希望能够在openEuler中找到对应everything的快速检索工具。

本题目为开放式,实现方式难度不等,可以去开源社区寻找优秀的业界实现,移植到openEuler平台;或借鉴已有实现,进行相关优化,目标是实现一个快速,可用,易用的文件检索工具。

P.S. 实现方式可以基于命令行或图形界面

难度

中等-困难

导师

@denggx_elros

联系方式

dengguangxing@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IELF

No61. - openEuler 集成 Kubernetes 相关软件包

描述 Kubernetes是用于自动部署,扩展和管理容器化应用程序的开源系统,也是如今云原生中最重要的底层基石之一。我们希望参与者能够提供Kubernetes相关软件在openEuler上的标准发布软件包,包括kubelet、kubectl等。并能够让用户在openEuler上更便捷地部署和使用kubernetes

难度

导师 @radeon92

联系方式 caoruidong@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IF4R

No.62 - QEMU 用户态进程热补丁框架

描述 * QEMU进程作为虚拟机进程需要常驻运行,但用户态软件发布上线后经常会存在一些紧急BUG需要在线修复; * 用户态热补丁技术是指在程序处于运行状态的时候,在线修改程序运行逻辑的技术,和内核态livepatch机制类似; * 相比内核态热补丁技术而言,用户态热补丁技术更具挑战性,用户态热补丁技术对云软件的可维护性具有重要意义; * 本题目要求参与者为例如QEMU之类的用户态进程实现一个简易的热补丁框架,能够为QEMU进程提供热补丁能力支持。

任务链接: * https://gitee.com/openeuler/marketing/issues/I1IG8E?from=project-issue

难度

导师 * @zhanghailiang * @yorifang

联系方式 fangying1@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IG8E

No.63 - openeuler 系统的内存统计工具

描述 请编写一个内存统计工具,能够统计openeuler系统中内核态内存使用情况,包括: 1.vmalloc内存都被谁申请了? 2.slab内存都被谁申请了? 3.内存page页都被谁申请了? 4.lru链表上的内存页都是哪些cache? 这些统计信息,可以通过proc接口设置和获取,并可以统计指定模块占用的内存。

难度

导师

  • @lvying6
  • @Pces
  • @licihua

联系方式

  • lvying6@huawei.com
  • chenjialong@huawei.com
  • licihua@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IGQC

No.64 - openEuler 集成 CRIU 工具

描述 CRIU是基于linux的用户态进程迁移软件,也是容器迁移的底层操作工具;CRIU可以完成用户态进程的Checkpoint/Restore操作,分别用于将进程所有相关运行状态保存到本地磁盘,以及根据磁盘文件恢复完全一致的进程。CRIU本身是纯用户态工具,但是依赖linux内核提供的相关能力,相应内核patch从3.8开始逐渐合入。

本次项目目标是将CRIU工具打包,加入openEuler发布件(基于X86和Arm64平台)

难度 中等

导师 @denggx_elros

联系方式 dengguangxing@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IGUG

No.65 - adler32算法在ARM平台的优化

描述 - Adler-32是马克·阿德勒(Mark Adler)在1995年发明的一种校验和 算法,是对弗莱彻校验和的一种改进。与相同长度的循环冗余校验相比,它以可靠性为代价(优先选择后者)。Adler-32比Fletcher-16更可靠,而可靠性却比Fletcher-32低。 - Adler-32在基础压缩库libz中使用,常见压缩和解压场景中,adler-32的算法热点会比较高,优化该算法可以提升libz基础库的性能。 - SIMD简介:单指令流多数据流(英语:Single Instruction Multiple Data,缩写:SIMD)是一种采用一个控制器来控制多个处理器,同时对一组数据(又称“数据向量”)中的每一个分别执行相同的操作从而实现空间上的并行性的技术。 - ARM平台使用SIMD优化adler-32的案例:https://developer.arm.com/architectures/instruction-sets/simd-isas/neon/neon-programmers-guide-for-armv8-a/neon-intrinsics-chromium-case-study/adler-32 使用SIMD向量指令优化adler-32性能能使PNG解码性能提升了5%~18%

难度

导师 @liqiang9102

联系方式 liqiang64@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IGXZ

No.66 - QEMU 中集成 virtio-fuzz 能力以支持模拟设备的模糊测试

描述 QEMU 中模拟大量设备(网卡、磁盘等),这些往往也是不可信的,甚至可能运行一些恶意软件,因此本课题目标在qemu中开发用于仿真设备的模糊测试;基于覆盖率反馈的启发式模糊测试(libfuzzer/AFL)被认为是一种较为有效的方式,可通过覆盖率反馈快速快速生成随机输入,而无需依靠人工指导;当前upstream社区提供两种实现方式:

  1. 基于libFuzzer:https://patchwork.kernel.org/cover/11393233/
  2. 基于AFL:https://kvmforum2019.sched.com/event/Tmv7/virtio-device-fuzzing-dmitrii-stepanov-yandex

可以选择一种将其移植到openEuler qemu中,并基于某种设备完成定制。

难度

导师 panny060

联系方式 pannengyuan@huawei.com

任务链接 https://gitee.com/openeuler/marketing/issues/I1IHCJ

No.67 - 基于需求覆盖度判断的用例筛选方法(RBC,requirement-based coverage)探索及工程构建

描述 OS内核及基础包众多,在代码迭代过程中,都需要执行大量自动化用例来保证修改的代码不会影响模块的原有功能。但是,现在的用例集和用例级别划分不是很明确,每次执行的用例有很多是冗余的。 如何准确的筛选出能够覆盖代码的最小用例集合,在尽量少的时间内完成迭代验证,提升OpenEuler的交付效率,是我们想要解决的问题。 通过执行用例时,跟踪用例覆盖到的代码分支和语句,可以有效识别出用例在代码中的覆盖范围,从而可以筛除冗余用例,构建精简的能够全面覆盖模块功能的用例集。

难度

导师 hw_niubility

联系方式 hw_niubility@yeah.net

任务链接 https://gitee.com/openeuler/marketing/issues/I1IHGJ

No.68 - 基于 Sealight 构建云手机的自动化测试

描述 云手机测试包括接口测试、集成测试、数据流测试、UI测试等多个维度的测试,代码层次多,接口多,且UI界面变化频繁,使用传统的测试工具,覆盖难度大。 使用Sealight等AI测试工具,深度扫描接口和UI,自动生成用例,提升用例开发效率

难度

导师 hw_niubility

联系方式 hw_niubility@yeah.net

任务链接 https://gitee.com/openeuler/marketing/issues/I1IHIT