关于 WebRTC 的源码下载和 Demo 的编译运行,WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例,过程大概是这样的:
- 下载并安装 depot_tools。这是 WebRTC 的代码下载及编译工具集,下载即是把源码 clone 下来,所谓安装只是把 depot_tools 的目录路径放进系统的环境变量 PATH 中即可。
关于 WebRTC 的源码下载和 Demo 的编译运行,WebRTC 的官方文档已经有非常详细的说明。以 Linux 为例,过程大概是这样的:
AddressSanitizer 是一个性能非常好的 C/C++ 内存错误探测工具。它由编译器的插桩模块(目前,LLVM 通过)和替换了 malloc
函数的运行时库组成。这个工具可以探测如下这些类型的错误:
互联网是一个分组(或者称为数据包)交换网络,其中传输的数据的基本单位是数据包。互联网中时时刻刻在发生的是距离有限的两个路由节点之间通过物理链路的数据包交换。那互联网中远距离复杂环境下的数据传输究竟如何完成的呢?它们正是借助于多次路由节点间直接的这种数据交换完成的。直觉上就让人觉得这种数据传输不是那么的可靠,不像电话网络连接那样。实际上互联网的数据传输确实不是百分之百的可靠,互联网上传输的数据天然地可能出现丢失,乱序,重复等等问题,但目前来看,绝大多数情况下,互联网还是比较有效。
Android QEMU 模拟器是我们日常 Android 开发中一个非常有力的工具,也是一套有很多值得玩的地方的系统,它还是开源的,主要由 Google Android 在维护。(Android QEMU 模拟器的源码下载、编译及调试方法可参考Android 模拟器下载、编译及调试)目前大多数开发者所用的开发机器都是 X86 架构的,因而 Google 官方对于Android QEMU 模拟器的编译和运行,也假设都是在 X86 架构平台进行的。这种假设在整个 Android QEMU 模拟器的编译和运行方面都有所体现,如编译配置仅提供了 X86 的相关选项,编译 Android QEMU 模拟器所需的一些预编译第三方库仅提供了X86 或 X86_64 的版本,编译脚本里仅有对 X86 或 X86_64 主机平台的行为定义,在代码中运行时一些关键的操作上仅有X86 或 X86_64 主机平台的定义等。
在知乎上看到了这个问题,借机总结一下自己在 Linux 内核学习研究上的经历和方法。
目前的工作实际上不是在搞 Linux 内核,但读大学的 4 年,其中有两年的时间在研究 Linux 内核和嵌入式 Linux。虽然已经好多年没再搞 Linux 内核,但上次项目需要,还是分析调试了 Android 的 low memory killer 驱动,并给 Android 的 binder 驱动增加了一些功能,对于 Linux 的内核的基本分析调试能力一直在。看到这个问题,分享一下自己的做法。
以我的理解,题主的问题可以分解为三个小问题,Linux 内核开发需要知道的基本背景知识,Linux 内核开发研究在技术上的路线图,以及 Linux 内核开发过程中的分析调试手法。