- 博客(126)
- 收藏
- 关注
原创 Ubuntu 虚拟机文件传输到 Windows的一种好玩的办法
本文介绍了在 Ubuntu 虚拟机中使用 Python HTTP 服务器向 Windows 主机传输文件的简便方法。主要内容包括:1)通过 python3 -m http.server 快速搭建文件服务器;2)获取虚拟机 IP 地址并在 Windows 浏览器访问;3)后台运行服务的方式(nohup/screen/tmux);4)配置 systemd 实现开机自启;5)安全注意事项和故障排查技巧。该方案适合临时文件共享需求,具有无需额外软件、跨平台访问和即用即走的特点。高级用户还可扩展为支持上传或使用 Ng
2025-11-13 18:19:30
991
原创 ARM交叉编译中编译与链接参数不一致导致的问题
本文深入分析了ARM交叉编译中因编译与链接阶段使用不同架构参数导致的ABI不匹配问题。详细探讨了ARMv8-A架构下的关键参数(-march、-mfpu、-mfloat-abi)的作用及影响机制,揭示了ABI不一致导致符号解析失败或运行时崩溃的原理。提供了CMake配置最佳实践、工具链验证方法及常见陷阱规避建议,强调必须确保编译和链接阶段使用相同的架构参数这一核心原则。通过统一项目配置、ABI验证和避免混合不同ABI的目标文件,可有效解决此类兼容性问题。
2025-11-13 15:52:15
597
原创 Windows 虚拟机配置与系统稳定性指南(VMware / Hyper-V)
避免虚拟机配置不当导致系统卡顿与损坏的指南 核心结论:Windows系统卡顿、异常重启与磁盘损坏的主要原因是主机内存压力过大引发换页风暴,而非CPU满载或虚拟化冲突。VMware不会直接破坏NTFS,但过度分配资源会导致主机资源紧张,最终因异常断电损坏文件系统。 关键防护措施: 内存分配:主机至少保留20%-30%物理内存,按主机内存合理分配VM内存。 vCPU分配:从主机逻辑处理器数的25%-50%起步,优先保持sockets≤2。 虚拟磁盘:避免长期堆叠快照,预分配更稳定,大型VM建议存放在独立SSD。
2025-09-28 14:17:57
1191
原创 我的创作纪念日
摘要: 本文分享了作者从嵌入式系统开发转向技术写作的心路历程。通过深入Linux内核源码的实践,作者认识到技术经验分享的价值,开始创作博客记录ARM、RISC-V等架构的开发经验,解决国产CPU适配等实际问题。创作带来了6000+同行的关注和产业界交流机会,其中RISC-V中断处理等文章产生实际工程价值。作者通过工作复盘、通勤构思等方式平衡创作与开发,未来计划推出操作系统内核设计系列、国产CPU解析专栏,并推动技术社区建设。文章强调技术分享对国产OS生态建设的促进作用,期待用代码和文字持续赋能开发者社群。(
2025-09-24 11:10:58
300
原创 Git工作区清理,确保提交时没有临时文件
本文深入解析了Git清理工作区的核心命令及其应用场景。重点对比了传统git checkout -- .与现代git restore .命令的差异,详解了git reset HEAD <path>和git clean -fd的用法。通过实战案例展示了如何解决复杂合并冲突,并提供了标准清理流程和最佳实践建议,包括安全预览、渐进式清理和脚本化操作。文中特别强调了操作安全,提醒开发者注意常见陷阱,如误删未跟踪文件和暂存区状态混乱等问题。这些命令和技巧的协同使用,能有效维护Git仓库的整洁性,提高开发效率
2025-09-24 10:50:09
429
原创 VMware 性能优化完整指南
本文档提供了针对 6 核 12 线程、32GB 内存配置的 VMware 虚拟机性能优化方案,确保 Linux 开发环境和 Windows 日常使用互不影响。解决虚拟化冲突:禁用 Hyper-V,启用硬件虚拟化合理资源分配:根据使用场景动态调整 CPU 和内存系统级优化:宿主机和虚拟机双重优化持续监控:通过性能监控工具验证优化效果遵循本指南的配置,可以在保证 Windows 日常使用流畅的前提下,获得接近原生的 Linux 开发环境性能。
2025-09-23 17:05:51
1471
原创 VMware虚拟机与Windows主机大文件传输解决方案:告别复制粘贴限制
本文介绍了在VMware虚拟机中实现Windows与Linux间无缝传输大文件的方法。通过使用开源VMware Tools配合fstab自动挂载设置,可完美解决官方工具的大文件传输问题。方案包含三个关键步骤:安装open-vm-tools、配置共享文件夹、设置fstab自动挂载。该方法支持任意大小文件传输,开机自动挂载,无需每次输入密码,且兼容性好。文中详细说明了实施步骤、故障排除和性能优化技巧,相比传统网络传输方式更稳定高效。该方案已在生产环境验证,是解决虚拟机文件共享问题的理想方案。
2025-09-23 15:13:00
1819
原创 Kconfig路径解析的“陷阱“:为什么相对路径不是你想的那样?
Kconfig路径解析机制解析 Kconfig系统的路径解析与直觉不同,所有source路径都相对于当前工作目录(CWD),而非Kconfig文件所在位置。这一特性在目录重构时容易引发问题:当将配置文件迁移到子目录后,相对路径引用会失效。正确解决方案是系统性地调整所有路径引用,使其从执行目录角度正确指向目标文件。设计上,Kconfig采用全局视角确保配置一致性,这与其他系统(如C的#include)基于文件位置的方式形成鲜明对比。关键是要理解Kconfig的路径计算始终基于pwd结果,而非文件相对位置。这一
2025-09-17 10:32:09
444
原创 深入解析:Windows批处理文件注释陷阱与最佳实践
Windows批处理文件注释使用指南 批处理文件中有两种注释方式:REM和::。REM是最安全可靠的注释方法,适用于所有位置,包括代码块内,支持任意缩进格式。而::注释虽然简洁,但使用受限,不能在缩进的代码块内使用,必须从行首开始,否则会被误认为命令。最佳实践是统一使用REM注释,特别是在代码块内必须使用REM。新项目建议采用REM作为标准注释风格,旧项目中的::注释应在维护时逐步替换为REM,以确保代码的可靠性和可维护性。
2025-09-09 16:17:00
298
原创 为什么链接顺序会影响符号解析?
在GCC链接过程中,库的顺序至关重要。链接器从左到右解析符号,若某个库依赖的符号在后续库中定义则能正确解析,反之会报错。对于浮点运算等底层实现,符号通常分布在libm、libgcc、libstdc++等库中。推荐链接顺序为:-lm -lc -lgcc -lstdc++,确保被依赖的库在前。C++项目尤其要注意将-lstdc++放在最后,因其依赖前面的库。错误的顺序会导致符号解析失败,特别是当-lstdc++先于-lgcc时,所需浮点运算符号将无法找到。
2025-07-29 17:20:01
479
原创 -lstdc++与-static-libstdc++的用法和差异
这个CMake配置组合了target_link_libraries和target_link_options两项功能:前者显式链接C++标准库(stdc++),后者指定静态链接方式(-static-libstdc++)。虽然看似重复,但实际作用不同:链接库确保标准库被包含,链接选项控制链接方式。这种写法在嵌入式开发中尤其重要,能确保程序静态链接C++标准库,避免运行时依赖动态库。二者配合使用是最保险的方案,适用于需要严格控制依赖的特殊编译场景。
2025-07-18 17:03:17
493
原创 CMake中WIN32和CMAKE_HOST_WIN32的使用差异
CMake中的WIN32和CMAKE_HOST_WIN32变量有本质区别: WIN32:判断目标系统是否为Windows,受CMAKE_SYSTEM_NAME影响,在project()后设置,用于配置目标平台相关代码(如添加Windows专用源文件) CMAKE_HOST_WIN32:判断CMake运行主机是否为Windows,不受CMAKE_SYSTEM_NAME影响,用于脚本级主机环境判断(如设置工具路径) 关键提示: 交叉编译时若设置CMAKE_SYSTEM_NAME=Generic会导致WIN32失
2025-06-30 17:05:48
506
原创 cmake支持include时添加文件搜索路径机制
CMake提供了类似C语言头文件搜索路径的机制,通过设置CMAKE_MODULE_PATH变量可以灵活管理模块文件的查找路径。本文对比了两种实现方式:推荐使用CMAKE_MODULE_PATH官方方法,将路径添加到模块搜索列表后可直接引用文件名;另一种是通过CMAKE_IMPLICIT_INCLUDE_DIRECTORIES全局设置(不推荐)。前者具有作用域可控、官方支持等优点,适用于工具链和函数库等模块化场景。使用时需注意在首次include前设置路径变量,并可通过message命令调试路径。建议在项目顶
2025-06-30 16:55:51
619
原创 Git 关于换行符LF和CRLF转换的警告
Git 关于换行符(LF/CRLF)转换的警告通常不会直接影响代码运行,但可能导致版本控制混乱(如diff干扰、合并冲突)或二进制文件损坏。主要影响场景包括:1)文本文件在跨系统协作时可能出现换行符不一致;2)误处理二进制文件会使其失效。解决方案建议:1)通过.gitattributes文件统一配置换行规则(如* text=auto eol=lf);2)团队约定统一换行标准;3)对Windows专用脚本(如.bat)需特别处理。长期项目推荐规范管理换行符以避免潜在问题。
2025-06-27 17:33:40
826
原创 Beyond Compare中三种比较方法的差异
文件比较工具中不同方法的本质差异在于比较的严格程度和关注点。基于规则的比较智能忽略格式差异(如空格、行尾、注释等),只判断内容逻辑是否一致;CRC比较通过校验值快速检测任何字节差异;二进制比较则逐字节严格对比。因此,规则比较可能显示"无差异"的文件,CRC/二进制比较会因格式细节差异报告"差异很大"。选择方法需根据需求:验证字节一致性用CRC/二进制比较,判断逻辑等价性则用规则比较。
2025-06-27 17:00:24
1636
原创 CMake 时间戳陷阱破解:如何让外部库更新自动触发重链接?
摘要: CMake构建时默认只检查源文件、CMake目标、自定义命令输出和依赖文件的时间戳,不检查外部静态库(.a文件)和系统库的时间戳。若需检测外部库更新,可采取以下方法:1)直接在target_link_libraries中添加库路径;2)使用IMPORTED目标建立依赖关系;3)使用--fresh参数强制重建。直接通过-l链接库无效,因CMake无法追踪文件路径。核心机制在于确保目标与外部库建立明确的依赖关系。(150字)
2025-06-10 17:38:09
294
原创 gcc还会有自己的头文件呢?
摘要: GCC编译器的头文件分布在多个目录中,各司其职: GCC自带头文件(.../include)提供与编译器内部机制相关的标准头文件(如stdarg.h),确保跨平台兼容性; 修正头文件(.../include-fixed)自动修复系统头文件的已知问题; 目标平台头文件(sys-include和include)存放交叉编译时使用的标准库头文件。 这种分层设计使GCC既能适配不同平台的标准库,又能保证自身功能的正确性。(150字)<|end▁of▁sentence|>
2025-05-21 17:10:13
467
原创 链接过程的两个阶段
机制作用层级控制阶段能否解决目标文件丢弃问题目标文件级库扫描阶段✅KEEP节区级链接脚本处理阶段❌(需目标文件已加载)-u symbol符号级全局符号解析✅(但需知道具体符号名)在嵌入式开发中,通常需要同时使用这些机制才能确保关键代码的可靠性。
2025-03-28 14:07:11
1057
原创 whole-archive与gc-sections
在嵌入式系统开发中,和是链接器(ld)的两个关键选项,它们的组合使用对最终二进制文件的构成有决定性影响。
2025-03-28 14:05:58
1300
原创 NuttX 中 Kconfig 变量的导出与子目录使用机制
Kconfig 系统提供用户友好的配置界面将配置转换为 CMake 变量这些变量在所有子目录中可用,用于条件编译子目录可以根据这些变量决定要编译哪些源文件和如何编译它们这种方法使 NuttX 能够根据用户的具体需求高度定制,只编译和链接必要的组件,从而优化最终二进制文件的大小和性能。
2025-03-18 14:59:15
916
原创 target_link_libraries影响编译顺序
关键问题在于:在子目录 CMakeLists.txt 中,bsp 依赖于 platform,所以 bsp 需要先等 platform 构建完成。但是 bsp 的构建(编译)是在。这确保在 bsp 库需要 platform 中的头文件时,platform 已经被正确处理。时触发的,这发生在 platform 目录处理之后但 bsp 的链接关系建立之前。确实会影响编译顺序,但前提是执行到这条命令时依赖关系已经建立。但这只影响 xxx 可执行文件的链接。现在应该能正确解决编译顺序的问题。
2025-03-18 10:46:25
454
原创 普通链接与whole-archive方式
如果同时使用两种方式,可能会导致符号重复或链接错误。中的 lxixihaha ,因为它已经通过。这就是为什么我们移除了。
2025-03-17 17:21:39
600
原创 cmake跨目录目标链接CMP0079
CMP0079 策略是关于 CMake 中跨目录目标链接的一个重要策略。添加源文件和链接库,使整个项目能够正常构建。这是一个现代 CMake 项目中常见的做法。是为了允许子目录(platform、application、board等)能够向主目标。
2025-03-17 15:57:32
499
原创 从脚本语言的角度了解cmake
这些特性使 CMake 成为一个功能强大的构建系统描述语言,能够处理复杂的构建需求。可见,cmake就是一个完整的脚本语言啊。
2025-03-12 14:18:57
429
原创 嵌入式开发中编译系统的现状与趋势分析
为配置系统的实际标准,二者共同支撑现代嵌入式开发的高效与灵活性。更多用于配置而非直接编译。是当前及未来嵌入式编译系统的核心,而。嵌入式开发中常用的编译系统主要包括。
2025-02-20 11:23:59
816
原创 文件系统中锁的作用
在文件系统(或其他并发系统中)中,。如果没有锁,多个线程或进程同时访问和修改共享资源时,可能会导致,从而引发一系列问题。以下详细解释为什么需要锁,以及如果没有锁会发生什么。
2025-01-21 16:17:08
1139
原创 符号扩展与逻辑扩展
*符号扩展(Sign Extension)逻辑扩展(Zero Extension)**是两种不同的数据扩展方式,它们的使用场景取决于操作的数据类型和具体的需求。
2025-01-17 09:59:58
1367
原创 文件描述符与VFS&&inode的关系
文件描述符(File Descriptor,简称 fd)是操作系统为用户空间程序提供的一个抽象概念,用于表示一个打开的文件或其他 I/O 资源(如管道、套接字等)。它是用户空间程序与内核之间进行文件操作的桥梁。下面我会详细解释文件描述符的概念、作用以及它与 VFS、inode 的关系。
2025-01-16 10:58:26
996
原创 网卡状态变更,virtio-net检测
现在在amp模式下linux端有个真实的物理网卡eth0,有一个虚拟网卡virtio-net0后端,此时需要一种机制,将真实物理网卡的状态发送rtos的virtio-net0前端。这里使用register_netdevice_notifier机制,每个virtio-net设备都有自己的notifier,支持多个virtio-net设备实例。在你的虚拟网卡驱动中,这个机制用于同步物理网卡和虚拟网卡的状态,确保虚拟网卡能正确反映物理网卡的工作状态。
2024-12-30 16:09:17
684
原创 platform_driver框架与早期设备树扫描
这种方式叫做"Early Device Tree Scanning"或"早期设备树扫描"。它是Linux内核提供的一种在驱动初始化早期阶段直接访问设备树的机制。在virtio_irq中,我们删除了platform_driver相关代码,删除了probe/remove函数,直接在init函数中获取设备树信息。为什么我没有采用设备驱动框架的方式,而是使用了早期设备树扫描?这种方式与platform_driver框架的区别?什么是早期设备树扫描?
2024-12-25 18:10:07
515
原创 串口是如何发送字符的?
当我们学习驱动的时候,往往最先了解的就是串口驱动。在我来看就是遵循硬件厂商的规则来操作寄存器用以初始化,使能特性,数据发送/接收的过程。但这不重要,在这里重要的是:串口是如何发送字符的?所以当我们说"等待发送缓冲区空闲"时,实际上是在等待 THR 寄存器可以接受新的数据。驱动在往THR写入数据,而THR又会自动向TSR写入数据,TSR呢?先看看串口的通信协议,只要设备端的串口驱动按照一种方式进行初始化,你连接的串口工具以同样的方式连接,就可以通信啦,不然可能是乱码。但还没有说:串口是如何发送字符的?
2024-12-10 17:05:03
1302
1
原创 OpenAMP 框架下 RPMSG 的原理与实现
每个 RPMsg 消息都包含在一个缓冲区中,该缓冲区存在于共享内存中。这个缓冲区由来自 vring 的缓冲区描述符池中的缓冲区描述符的地址字段指向。这个缓冲区的前 16 个字节由传输层(RPMsg 层)内部使用。第一个字(32 位)用作发送方或源端点的地址下一个字是接收方或目标端点的地址。出于对齐原因有一个保留字段(因此 RPMsg 头部是 16 字节对齐的)。头部的最后两个字段是有效负载的长度(16 位)和一个 16 位的标志字段。
2024-11-21 11:03:27
2908
原创 littlefs源码分析1-设计思考
在一个完全不同的方向上,我们有日志文件系统,例如JFFS、YAFFS和SPIFFS,存储位置不与一块数据绑定,相反,整个存储用于一个循环日志,每次对文件系统进行更改时都会追加到该日志中。写时复制文件系统与其他基于块的文件系统非常相似,但不是就地更新块,而是通过创建带有更改的副本并将对旧块的任何引用替换为我们的新块来执行所有更新。这会递归地将我们所有的问题向上推,直到我们到达文件系统的根,而文件系统的根通常存储在一个非常小的日志中。首先,我们有非弹性的、基于块的文件系统,例如 FAT 和 ext2。
2024-10-24 16:59:07
1491
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅