Lmiracle

简介本博客基于 Hexo 搭建，使用 Butterfly 主题，部署在 GitHub Pages 上。Hexo 是一款快速、简洁且高效的静态博客框架，使用 Markdown 写作，一键生成静态页面，非常适合技术博客。 本文记录从零搭建到日常使用的完整流程。 环境准备依赖 Node.js >= 18 Git 安装 Hexo CLI12345# 全局安装（需要权限）sudo npm install -g hexo-cli# 验证hexo --version 初始化博客123hexo init my-blogcd my-blognpm install 目录结构如下： 12345678my-blog/├── _config.yml # 站点主配置├── package.json├── scaffolds/ # 文章模板├── source/│ └── _posts/ # 博客文章├── themes/ # 主题└── public/ # 生成的静态文件（自动生成） 安装 B ...

mqtt broker简介和选型MQTT Broker（mqtt代理服务器），负责管理和转发消息，关于细节不在赘述。关于broker选型，需要考虑使用场景、性能、易用性和支撑的特性等。 目前主流的mqtt broker有mosquitto、EMQX、HiveMQ、VerneMQ、Amazon AWS IoT Core等，由于需要跑在RTOS上，只需要简单转发消息即可，故选择mosquitto。 移植过程中需要考虑的问题 问题1，根据使用场景，优先裁剪config文件 问题2，仅保留mosquitto原文件和调用lib文件，删除多余app、test等文件 问题3，解决类型匹配，RTOS中头文件类型可能有冲突 问题3，由于mosquitto只支持用epoll和poll机制，而ECOS只支持select，故使用select分装poll函数 问题4，mosquitto是配置文件的方式传入配置信息，考虑配置文件加载 问题6，mosquitto中存在信号机制，考虑相关RTOS是否支持信号 移植梳理每个目录，修改删除不必要的文件，如：test、doc、docker等目录。顶层Make只需要编译sr ...

背景工作中经常遇到驱动相关问题，之前对驱动开发也是现学现买。准备系统接触linux驱动驱动和kernel，刚开始主要熟悉linxu驱动框架，不涉及相关硬件（后续可能回学习ARM或RISC-V）。打算在自己的主机上编译kernel模块，直接调试加载。 环境 ununtu 24.04 kernel版本 12$ uname -r6.8.0-31-generic 源码和分析第一个简单的驱动以hello.c命令，代码中只有module init和module exit. 1234567891011121314151617181920#include <linux/module.h>#include <linux/cdev.h>int hello_init(void){ printk("hello world! init.\n"); return 0;}void hello_exit(void){ printk("hello world! exit.\n"); return;& ...

netif_receive_skb简介netif_receive_skb作用： 把接收帧传给每个协议分流器 把接收帧传给skb->protocol所关联的L3协议处理函数。 负责L2必须的功能处理 如果某接收帧数据没有关联skb->protocol，而且L2没有处理该帧，kernel不知道如何处理该帧数据，会将起丢弃。 skb->protocol：一般由驱动接收程序赋值，从L2层设备驱动程序的角度看，就是用在下一个较高层的协议。如：IP、IPv6以及ARP等；值在include/linux/if_ether.h中。由于每种协议都有对应的处理函数，因此驱动程序使用该字段告诉上层程序对应协议。 netif_receive_skb() 是主要的接收数据处理函数。它总是成功。 缓冲区可能会在拥塞控制处理期间或被协议层丢弃。此函数只能从软中断上下文调用，并且应启用中断。 如果桥接代码或者入口流量控制没有处理该帧数据，则该帧会传给L3协议处理函数（通常每种协议只有一个处理函数，但是也可以注册多个）。 至此，接收部分已经完成。 L3对封包的处理： 传递 ...

简介站在内存管理的角度看eCos操作系统，就是一个进程。eCos系统中只有线程概念（任务），并没有进程概念。整个内存规划简单看就是一个进程的内存分布。 既然一个进程，内存中会有text、data、bss、heap段等。 💡 eCos线程的栈就是一块buf（内存），可以是全局buf，也可以从heap上申请。 eCos查看内存1234567891011121314151617181920212223 mbuf twork stack mbuf stats: mbufs 69, clusters 2360, free clusters 56 Failed to get 0 times Waited to get 0 times Drained queues to get 0 timesVM zone 'ripcb': Total: 32, Free: 31, Allocs: 88, Frees: 87, Fails: 0VM zone 'divcb': Total: 2, Free: 2, Allocs: 0, Free ...

背景国内三大运营商宽带布局普遍使用光猫+路由器的方式（FTTR虽然运营商在主推，目前并不普及）。光猫无线能力较弱或者不支持无线，路由器将承载用户主要上网需求。但是普通家庭网线只布置一条（光猫放弱点箱，路由器在电视柜），上网和IPTV同时支持需要光猫配置单线复用。 一条网线同时支持上网和IPTV业务，国内通常上网业务不带vlan tag，IPTV业务带vlan tag。此时路由器可以通过vlan tag区分业务流，将IPTV业务转发到路由器IPTV口。目前运营商送的路由器都支持该功能，国内主流厂商家用路由器也支持该功能。 拓扑 问题描述电视盒子播放电视过程中，概率出现PC有线接入LAN1/LAN2后IPTV停止播放， 问题分析 PC连接网线后会主动发送IGMP加组报文，路由器接收到后，会通过WAN口请求加组，该加组报文由于是LAN1或LAN2输入，并不会携带tag。 光猫收到没有带tag的IGMP报文，会导致原有的IPTV组播流从带tag下发变成不带tag下发。（问题根源） 路由器由以前带tag报文通过vlan tag来识别IPTV业务流，此时，路由器并没有对应的组播路由来转发 ...