第17届开源开发工具大会（OSDT2025）议程公布，观众报名开启- 大数跨境

首页

第17届开源开发工具大会（OSDT2025）议程公布，观众报名开启

GTOC

2025-12-03

导读：12 月 7 日周日下午 2 点开始，腾讯会议。

如果您曾经投递过稿件但是没有得到回复，请通过邮件（Lazyparser@gmail.com）或在 HelloGCC 微信公众号后台联系组织方，避免我们因为遗漏邮件而错过您的分享。

时间

时间：2025年12月7日周日， 2PM - 6PM

地点：线上会议

报名入口： https://meeting.tencent.com/dw/VnA8EVnUf2NZ

B站直播地址（随缘）

当 Webinar 人数超过100后启用
lazyparser直播间，房号10339607
https://live.bilibili.com/10339607

议程

时间演讲人题目
14:00 吴伟《OSDT社区2025回顾》
14:10 邱吉《HelloLLVM社区2025回顾》
14:25 泽文《Rust for QEMU：架构演进、现状分析与贡献指南》
14:50 蒙卓《mini-compiler-for-math-Go》
15:15 陈力《我的 git rebase trailer 机制的实现》
15:40 罗云翔 《RuyiSDK：为RISC-V开发者构建的全栈开发环境》
16:05 刘明阳 《MLIR Python：通过 Python 编写编译器的关键流程》
16:30 刘子悦 《MoonLLVM，小型编译框架也有大作为》
16:55 ChenMiao 《基于Capstone的Rust重构与RISC-V反汇编生态实践》
17:20 蒋明辉 《将 eBPF 扩展到 GPU 设备上下文》

演讲内容简介（部分）

陈力 - 我的 git rebase trailer机制的实现

我希望能在OSDT 2025上介绍下我最近半年在空余时间给git project上做的一个功能和心得体会，git rebase trailer，下面是社区链接： https://lore.kernel.org/git/20251105142944.73061-1-me@linux.beauty/ 目前还在实现v7中。

罗云翔 - RuyiSDK：为RISC-V开发者构建的全栈开发环境

报告介绍：RuyiSDK致力于为RISC-V开发者提供一套完整、全栈且功能强大的开发工具链。该平台全面覆盖编译、调试、模拟等关键开发环节，提供全流程支持，并广泛兼容当前市场主流RISC-V开发板和提供通用安装功能，旨在为开发者打造真正的一站式开发体验。本次报告将系统介绍RuyiSDK的使用方法，内容包括：RuyiSDK包管理器的安装步骤、RuyiSDK在开发板上安装操作系统的具体流程，以及如何利用RuyiSDK中的编译工具链进行开发。此外，报告也将分享RuyiSDK在测试与版本发布方面的流程与实践经验。

刘明阳 - MLIR Python：通过 Python 编写编译器的关键流程

最近，我向 MLIR 上游贡献了一系列的 patch，主要聚焦于 MLIR Python bindings，这些 patch 使得用户能够在不编写 C++ 的情况下，通过 Python 为 MLIR 编写新的 optimization/lowering pass、加入新的 rewrite patterns（通过 RewritePatternSet 或 PDL），或是通过 IRDL 定义新的 dialects。这些工作的初衷是，先前编译器开发者在 MLIR 的开发中需要编写 C++ 代码并处理各种构建问题，将一部分时间投入编译过程中，而通过 Python 则可以快速地进行原型验证，以优化编译器开发的体验。Talk 主要面向 MLIR 的用户，讲解如何通过 Python 来编写 pass, pattern 以及 dialect。

ChenMiao - 基于Capstone的Rust重构与RISC-V反汇编生态实践

我们拟围绕以下方向展开交流：

Robustone项目的设计理念与技术路线
Robustone RISC-V Online项目的设计理念与技术路线
Robustone RISC-V Online Vscode Plugin项目的设计理念与技术路线
当前已实现的反汇编能力覆盖范围（支持的指令集版本/扩展列表）及实际应用案例
对RISC-V反汇编工具链生态发展的思考与未来规划

蒋明辉 - 将 eBPF 扩展到 GPU 设备上下文

GPU 广泛用于机器学习工作负载，通常是 SIMT 加速器，线程以线程束的形式分布在 SM 上，并被组织成块，作为内核启动，使用多级内存层次结构（寄存器、共享/LDS、L2 缓存、设备内存）和有限的抢占机制。这种复杂性造就了丰富但又极具挑战性的行为模式，给可观测性和定制化带来了困难。目前，许多用于 GPU 工作负载的跟踪工具都位于 CPU 边界（例如，CUDA 用户空间库或内核驱动程序的探针），这虽然可以提供主机端的事件信息，但却将设备视为一个黑盒：对运行中的内核内部的可见性很低，与停顿或内存流量的关联性较弱，而且没有安全的方法在运行时调整行为。GPU 专用分析器（例如 CUPTI、GTPin、Nvbit、Neutrino）提供了设备端的可见性，但它们通常与 eBPF 流水线隔离，难以与 CPU 上的事件关联起来。

我们通过定义 GPU 端连接点（CUDA 设备函数入口/出口、线程开始/结束、屏障/同步、调度操作等）并将 eBPF 程序编译成设备字节码（PTX/SPIR-V），实现了将 eBPF 卸载到 GPU 设备上下文的原型设计。该原型设计还包含验证器、辅助程序和映射支持，用于设备端执行。该方法基于 bpftime，速度比 NVBit 快 3-10 倍，不受厂商限制，并且可以与 Linux 内核 eBPF 程序（例如 kprobes 和 uprobes）配合使用。这使得 GPU 扩展功能得以实现，例如在 GPU 线程、线程束或指令级别进行细粒度分析，自适应 GPU 内核优化，以及使用 eBPF 实现 GPU 线程的可编程调度。此外，它还可以帮助加速一些现有的 eBPF 应用程序。

本次演讲的目标是探讨将 eBPF 编程模型扩展到 GPU 的用例、挑战和经验教训。

https://github.com/eunomia-bpf/bpftime/tree/master/example/gpu