碎碎念念

总览

当前项目github仓库：https://github.com/LunarStore/onvif_srvd。

onvif服务原参考项目：https://github.com/KoynovStas/onvif_srvd/tree/master，原项目当中，作者把服务发现和onvif服务分成了两个项目。我已经将这两项目合并，onvif_srvd包含服务发现与onvif服务。onvif_srvd实现了Onvif所需的最少接口。（注意：甚至连Profile S标准都未达到，并且为了适配H265，引入了media2.wsdl，按规范来讲我们需要完整的实现Profile T标准）

调试工具：ODM + OnvifTestTool。

Onvif Device Test Tool工具能高效帮忙对onvif服务进行调试，可以利用Onvif Device Test Tool查看和分析 来自onvif服务的gsoap报文。如果你需要开发onvif，该工具一定要学会使用！！！它一定能是你调试onvif的利器。

onvif服务项目结构：

前言

参考：

• Hexo基本环境搭建: https://blog.csdn.net/weixin_45019350/article/details/121901433。
• NexT主题仓库：https://github.com/theme-next/hexo-theme-next
• NexT主题使用配置教程：NexT主题使用配置教程文档
• Vercel部署Hexo博文：vercel部署hexo

也是一时兴起，花了两三天时间使用Hexo搭建了一个个人博客，个人博客链接： https://www.halfmantou.xyz/ 。目前已经将CSDN所有的博客迁移过去了。当然为了通用性，CSDN的博客还是会持续同步更新。

搭建和部署的过程当中也是或多或少遇到了一些奇奇怪怪的问题，于是特意写此篇阅读来记录一些点点滴滴。

正文

实现方式其实是参考 buildroot/package/pkg-cmake.mk 的代码，你必需知道，我们再向buildroot添加一个包时，会编写mk文件，里面会有很多预定义的宏，最常见的：XX_INSTALL_STAGING_CMDS 和 XX_INSTALL_TARGET_CMDS，两者区别是：XX_INSTALL_STAGING_CMDS是往构建根目录安装一些文件、XX_INSTALL_TARGET_CMDS是往目标（下位机根文件系统）目录安装一些文件。一旦我们的mk文件定义了这两命令，这两命令的默认值就会被覆盖。

XX_INSTALL_STAGING_CMDS 和 XX_INSTALL_TARGET_CMDS这两命令的默认行为就是使用原项目当中的cmake install代码。我们只需要参考 buildroot/package/pkg-cmake.mk 文件默认安装命令的实现，然后再此基础上自定义我们的内容就能实现“双install”的效果。

废话不多说，直接上代码：

前言

拖了这么久，终于到了最后一篇关于类unix源码分析的文章————文件系统。

（偷偷告诉你，本篇博客起草于我即将从毕业以来第一家公司离职前一个星期（2025-9-16），忍着牙痛ing ing ing）。

如你所见，文件系统完全值得另开一篇博文单独去记录它。这里为了方便，同样将Onix的文件系统和XV6的文件系统放一块进行记录。并且，Onix的文件系统确实更加规范和完善，而XV6的文件系统相对来说更加简洁。但值得一提的是，XV6文件系统实现了一个简单而确实又很重要的东西————基于写时日志的事务系统。这是Onix所没有的。

linux的一切皆文件的伟大思想，将所有的IO行为（包括IO设备读写、pipe读写、进程读写）都抽象成文件。在本篇文章当中，我们将通过两个小型操作系统源码一一揭开linux文件系统的面纱。

什么是Flow？

从字面意思上理解，Flow就是流，在音视频领域，常常就能听到什么视频流、音频流，当然这些都可以统称为数据流。

在RKMedia当中，也存在一套基于Flow（流）的专门处理音视频流的框架。这里面还牵扯pipeline的概念，所谓pipeline就是一条独立的流水线，当每一帧的原始视频图像（一般是nv12格式）流入某条流水线后，会经过一些加工处理（比如对原始图像进行缩放、裁剪、编码等），最后输出的这一帧成品数据才会被推流到服务器，具体对一帧图像的加工就是由Flow负责，当然RKMedia把流水线思想用的特别精妙，因为加工也会分很多工序，所以对应的Flow的派生类也会分很多种。每种flow分工明确，只关注自己应该对图像的那一小部分工序，然后就把加工后的图像传递给下一级flow。

这里贴一张图，方便理解pipeline和Flow：

source flow会从相机当中读取图像数据。

前言

首先说明一下StorageManager在IPC中起到的作用：从英文命名可以大致猜出它的作用——存储管理，主要功能就是维护存储的目录结构以及数据库。

进一步的：这些目录里面会放什么？数据库里面会放什么？

下面一一回答这些问题：

1. 目录主要会存放手动/自动录制的视频以及抓拍的照片。

2. 数据库主要记录录制视频、照片的文件名。在网页如下页面中的视频/照片列表的数据来源就是这个数据库。

如下表数据就来自StorageManager独自维护的数据库当中：

前言

自动升级旨在通过无人机更新负载上的软件，包括不限于：Payload-SDK应用、配置文件等。对于文件的传输，大疆的Payload-SDK给我们提供了两种方式：使用FTP协议和使用大疆自研的DCFTP。我们实现的自动升级是基于FTP。所以自动升级的实现可以分成3个部分：

• FTP服务的搭建
• Payload-SDK应用的修改
• sh包的制作与sh打包脚本的编写

FTP服务的搭建

参考大疆官方做法：链接。

首先我们需要在负载上搭建一个vsftp服务。我司使用的是正点原子的rk3588，而rk3588默认已经在buildroot当中引入vsftp服务，我们重点只需要配置ftp配置文件：/etc/vsftpd.conf即可。配置参考如下（完整配置，可直接copy使用）：

SonarQube介绍

Sonar (SonarQube)是一个开源平台，用于管理源代码的质量。支持Java、kotlin、Scala、python、JavaScrip等二十几种编程语言的代码质量管理与检测。支持将代码扫描集成到现有的工作流，以便在项目分支和拉取请求之间进行连续的代码检查。

分为社区版、开发版、企业版数据中心版。对于静态检测，只有开发版、企业版支持C/C++，而我们的业务以C/C++为主，故选择需要破解的企业版。

安装

环境搭建参考博客：https://www.codestar.top/2024/10/10/Linux/Ubuntu-docker%E6%90%AD%E5%BB%BAsonarqube%E7%A4%BE%E5%8C%BA%E7%89%88/

Docker安装PostgreSQL容器

前言

谈到Flow其实绕不开Pipeline的概念，而Pipeline就是字面意思——流水线。一条Pipeline由多个flow节点构成。每个flow节点会对输入进来的数据做特殊的处理，再将数据发送给下一级flow节点，因此不同的flow节点承担不同的任务。

在数据库领域也存在PipeLine的工程实践：一条查询sql语句最终会被解析成一个个查询计划（查询计划会被连接成Pipeline形式的树形结构），执行器会利用所绑定的查询计划，对传来的表数据进行处理，然后讲处理好的表数据传递给下一级节点。这里放上一张一条聚合查询语句被解析后所构建的Pipeline模型：

上图是如下sql语句被解析后所构建的Pipeline：

前言

笔者使用开发板型号：正点原子的IMX6ULL-alpha开发板。ubuntu版本为：20.04。写此文也是以备忘为目的。

字符设备驱动

本小结将以直接操作寄存器的方式控制一个LED灯，可以通过read系统调用可以获取灯的状态（开/关）；通过write系统调用可以控制灯的开关。

LED原理图如下：

从图中可以了解到，我们需要控制LED0所接的GPIO口输出低电平可以点亮led灯，输出高电平可以关闭led灯。查手册得知LED0对应为GPIO1_IO03。