1.Nacos 服务注册源码分析
2.搭建nextcloud私有云存储网盘的最新教程详解
3.源码详解系列(八)--全面讲解HikariCP的使用和源码
4.怎样才能让cpps文件生成exe文件？
5.linux中cp命令如何用 C语言实现
6.[转]Megatron-LM源码系列(八)： Context Parallel并行

Nacos 服务注册源码分析

       文章标题：Nacos 服务注册源码深度剖析

       作者郑哥在微信公众号运维开发故事中，详细解析了Nacos服务注册过程中服务端和客户端的源码源码运作机制。以Spring-Boot为基础，下载Nacos在服务架构中扮演着中心角色，最新与Eureka、源码源码Zookeeper等其他中间件相区分，下载源码对接后台其特点是最新支持AP和CP模式，并采用Raft协议保证分区一致性。源码源码

       客户端注册服务是下载主动的，通过Spring-Cloud Alibaba组件集成。最新关键配置类NacosServiceRegistryAutoConfiguration定义了核心Bean，源码源码如NacosAutoServiceRegistration，下载它负责将服务实例注册到Nacos。最新NacosServiceRegistry则负责实际的源码源码注册操作，通过心跳机制保持与服务端的下载连接。

       服务端，Nacos根据客户端注册时的ephemeral属性决定使用Distro（AP）或Raft（CP）协议。AP模式下，Nacos通过udp更新服务实例信息，而CP模式下，会触发raftCore.signalPublish进行数据同步和通知。

       对于源码调试，郑哥分享了如何定位启动类com.alibaba.nacos.Nacos，cskin最新源码以及如何通过IDEA进行启动和调试。要深入了解Nacos的源码，可以参考nacos.io和github.com/alibaba/nacos...的文档。

搭建nextcloud私有云存储网盘的教程详解

       Nextcloud是一款开源免费的私有云存储网盘项目，可以让你快速便捷地搭建一套属于自己或团队的云同步网盘，从而实现跨平台跨设备文件同步、共享、版本控制、团队协作等功能。它的客户端覆盖了Windows、Mac、Android、iOS、Linux 等各种平台，也提供了网页端以及 WebDAV接口，所以你几乎可以在各种设备上方便地访问你的云盘。

       简介：

        搭建个人云存储一般会想到ownCloud，堪称是自建云存储服务的经典。而Nextcloud是ownCloud原开发团队打造的号称是“下一代”存储.

        真正试用过后就由衷地赞同这个Nextcloud：它是个人云存储服务的绝佳选择。一开始以为Nextcloud只是一个网盘云存储，后来看到

        Nextcloud内置了Office文档、相册、winxp系统源码泄露日历联系人、两步验证、文件管理、RSS阅读等丰富的应用，我发现Nextcloud已经仅仅可以

        用作个人或者团队存储与共享，还可以打造成为一个个人办公平台，几乎相当于一个个人的Dropbox了。Nextcloud运行环境与平常我们

        常用的程序差不多，LAMP是官方首选，不过LNMP也照样可以运行，只不过需要自己写URL重写规则。当然，官方还提供了SNAP一键安装包

        注：以上来自网上某处，重点是下面的安装

       本篇采用rpm源码安装，本人亲测有效，在线或一键安装没难度，请自行百度，

       1.安装LAMP架构:

       注：为了避免权限，网络问题等请用root用户或较高级别账号登录再操作

       yum install -y tl.h>

       #include <errno.h>

       #include <unistd.h>

       #include <string.h>

       #define BUF_SIZE 

       #define PATH_LEN 

       void my_err(char *err_string, int line )

       {

           fprintf(stderr,"line:%d ",line);

           perror(err_string); 

           exit(1);

       }

       void copy_data(const int frd,const int fwd)

       {

           int read_len = 0, write_len = 0;

           unsigned char buf[BUF_SIZE], *p_buf;

           while ( (read_len = read(frd,buf,BUF_SIZE)) ) {

               if (-1 == read_len) {

                   my_err("Read error", __LINE__);

               }

               else if (read_len > 0) {  //把读取部分写入目标文件

                   p_buf = buf;

                   while ( (write_len = write(fwd,p_buf,read_len)) ) {

                       if(write_len == read_len) {

                           break;

                       }

                       else if (write_len > 0) {  //只写入部分

                           p_buf += write_len;

                           read_len -= write_len;

                       }

                       else if(-1 == write_len) {

                           my_err("Write error", __LINE__);

                       }

                   }

                   if (-1 == write_len) break;

               }

           }

       }

       int main(int argc, char **argv) 

       {

           int frd, fwd; //读写文件描述符

           int len = 0;

           char *pSrc, *pDes; //分别指向源文件路径和目标文件路径

           struct stat src_st,des_st;

           if (argc < 3) {

               printf("用法 ./MyCp <源文件路径> <目标文件路径>\n");

               my_err("arguments error ", __LINE__);

           }

           frd = open(argv[1],O_RDONLY);

           if (frd == -1) {

               my_err("Can not opne file", __LINE__);

           }

           if (fstat(frd,&src_st) == -1) {

               my_err("stat error",__LINE__);

           }

           /*检查源文件路径是否是目录*/

           if (S_ISDIR(src_st.st_mode)) {

               my_err("略过目录",__LINE__);

           }

           pDes = argv[2];

           stat(argv[2],&des_st);

           if (S_ISDIR(des_st.st_mode)) {  //目标路径是目录，则使用源文件的文件名

               len = strlen(argv[1]);

               pSrc = argv[1] + (len-1); //指向最后一个字符

               /*先找出源文件的文件名*/

               while (pSrc >= argv[1] && *pSrc != '/') {

                   pSrc--;

               }

               pSrc++;//指向源文件名

               len = strlen(argv[2]); 

               // . è¡¨ç¤ºå¤åˆ¶åˆ°å½“前工作目录

               if (1 == len && '.' == *(argv[2])) {

                   len = 0; //没有申请空间，后面就不用释放

                   pDes = pSrc;

               }

               else {  //复制到某目录下，使用源文件名

                   pDes = (char *)malloc(sizeof(char)*PATH_LEN);

                   if (NULL == pDes) {

                       my_err("malloc error ", __LINE__);

                   }

                   strcpy(pDes,argv[2]);

                   if ( *(pDes+(len-1)) != '/' ) {  //目录缺少最后的'/'，则补上’/‘

                       strcat(pDes,"/");

                   }

                   strcat(pDes+len,pSrc);

               }

           }

           /* æ‰“开目标文件， ä½¿æƒé™ä¸Žæºæ–‡ä»¶ç›¸åŒ*/ 

           fwd = open(pDes,O_WRONLY | O_CREAT | O_TRUNC,src_st.st_mode);

           if (fwd == -1) {

               my_err("Can not creat file", __LINE__);

           }

           copy_data(frd,fwd);

           //puts("end of copy");

           if (len > 0 && pDes != NULL)

               free(pDes);

           close(frd);

           close(fwd);

           return 0;

       }

[转]Megatron-LM源码系列(八)： Context Parallel并行

       原文链接： Megatron-LM源码系列(八)： Context Parallel并行

       Context Parallel并行(CP)与sequence并行(SP)相比，核心差异在于SP只针对Layernorm和Dropout输出的activation在sequence维度进行切分，而CP则进一步扩展，对所有input输入和所有输出activation在sequence维度上进行切分，蓝光过滤源码形成更高效的并行处理策略。除了Attention模块外，其他如Layernorm、Dropout等模块在CP并行中无需任何修改，因为它们在处理过程中没有涉及多token间的交互。

       Attention模块之所以特殊，是因为在计算过程中，每个token的查询(query)需要与同一sequence中其他token的键(key)和值(value)进行交互计算，存在内在依赖性。因此，在进行CP并行时，计算开始前需要通过allgather通信手段获取所有token的KV向量，反向计算时则通过reduce_scatter分发gradient梯度。

       为了降低显存使用，前向计算阶段每个GPU仅保存部分KV块，反向阶段则通过allgather通信获取全部KV数据。这些通信操作在特定的rank位置（相同TP组内）进行，底层通过send和recv等操作实现allgather和reduce_scatter。

       以TP2-CP2的transformer网络为例，CP并行的通信操作在Attention之前执行，其他则为TP通信。AG表示allgather，美团源码详解RS表示reduce_scatter，AG/RS表示前向allgather反向reduce_scatter，RS/AG表示前向reduce_scatter反向allgather。

       TP2对应为[GPU0, GPU1], [GPU2, GPU3]，CP2指的就是TP组相同位置的rank号，即[GPU0, GPU2], [GPU1, GPU3]。CP并行类似于Ring Attention，但提供了OSS与FlashAttention版本，并去除了冗余的low-triangle causal masking计算。

       LLM常因序列长度过长而导致显存耗尽（OOM）。传统解决方法包括重计算或扩大TP（tensor parallel）大小，但各自存在计算代价增加或线性fc计算时间减少与通信难以掩盖的问题。CP则能更高效地解决这一问题，每个GPU处理一部分序列，同时减少CP倍的通信和计算量，同时保持TP不变，使得activation量也减少CP倍。性能优化结果展示于图表中，用户可通过指定--context-parallel-size在Megatron中实现CP。

       具体源码实现以Megatron-Core 0.5.0版本为例进行说明。

OpenHarmony 3GPP协议开发深度剖析——一文读懂RIL

       市场上针对终端操作系统3GPP协议开发的相关资料较为稀缺，即便在Android领域，相关学习文档也较为有限，更不用说专门的协议开发书籍了。这可能与市场需求有关，目前市场上从事前后端软件开发的人员最多，包括我自己。

       鉴于我在某手机协议开发团队工作过一段时间，对协议的AP侧和CP侧开发都有所涉猎，因此我尝试基于OpenAtom OpenHarmony（以下简称“OpenHarmony”）源码编写一些内容，旨在帮助大家了解协议开发领域，尽可能将3gpp协议内容与OpenHarmony电话子系统模块相结合进行讲解。据我所知，目前终端协议开发人才非常紧缺。首先声明，我不是协议专家，且已离开该领域五六年，如有错误，欢迎指正。

       谈到终端协议开发，我首先想到的就是RIL。

       CP：Communication Processor（通信处理器），通常理解为modem侧，也可以理解为底层协议，这部分由各个modem芯片厂商完成（如海思、高通）。

       AP：Application Processor（应用处理器），通常指手机终端，通常理解为上层协议，主要由操作系统Telephony服务进行处理。

       RIL：Radio Interface Layer（无线电接口层），通常理解为硬件抽象层，即AP侧将通信请求传给CP侧的中间层。

       AT指令：AT指令是应用于终端设备与PC应用之间连接与通信的指令。

       常规的Modem开发与调试可以使用AT指令进行操作，而各家的Modem芯片的AT指令都会有各自的差异。因此，手机终端厂商为了能在各种不同型号的产品中集成不同modem芯片，需要进行解耦设计来屏蔽各家AT指令的差异。

       于是，OpenHarmony采用RIL对Modem进行HAL（硬件抽象），作为系统与Modem之间的通信桥梁，为AP侧提供控制Modem的接口，各Modem厂商则负责提供对应于AT命令的Vender RIL（这些一般为封装好的so库），从而实现操作系统与Modem间的解耦。

       框架层：Telephony Service，电话子系统核心服务模块，主要功能是初始化RIL管理、SIM卡和搜网模块。对应OpenHarmony的源码仓库OpenHarmony/telephony_core_service。这个模块也是非常重要的一个模块，后期单独再做详细解读。

       硬件抽象层：即我们要讲的RIL，对应OpenHarmony的源码仓库OpenHarmony/telephony_ril_adapter。RIL Adapter模块主要包括厂商库加载，业务接口实现以及事件调度管理。主要用于屏蔽不同modem厂商硬件差异，为上层提供统一的接口，通过注册HDF服务与上层接口通讯。

       芯片层：Modem芯片相关代码，即CP侧，这些代码各个Modem厂商是不开放的，不出现在OpenHarmony中。

       硬件抽象层又被划分为hril_hdf层、hril层和venderlib层。

       hril_hdf层：HDF服务，基于OpenHarmony HDF框架，提供hril层与Telephony Service层进行通讯。

       hril层：hril层的各个业务模块接口实现，比如通话、短彩信、数据业务等。

       vendorlib层：各Modem厂商提供的对应于AT命令库，各个厂商可以出于代码闭源政策，在这里以so库形式提供。目前源码仓中已经提供了一套提供代码的AT命令操作，至于这个是针对哪个型号modem芯片的，我后续了解清楚再补充。

       下面是ril_adapter仓的源码结构：

       本文解读RIL层很小一部分代码，RIL是如何通过HDF与Telephony连接上的，以后更加完整的逻辑梳理会配上时序图讲解，会更加清晰。首先，我们要对OpenHarmony的HDF（Hardware Driver Foundation）驱动框架做一定了解，最好是动手写一个Demo案例，具体的可以单独去官网查阅HDF资料。

       首先，找到hril_hdf.c文件的代码，它承担的是驱动业务部分，源码中是不带中文注释的，为了梳理清楚流程，我给源码关键部分加上了中文注释。

       上述代码中配置了对应该驱动的moduleName为"hril_hdf"，因此我们需要去找到对应驱动的配置文件，以HiDV开发板为例，它的驱动配置在vendor_hisilicon/HiDV/hdf_config/uhdf/device_info.hcs代码中可以找到，如下：

       这里可以发现该驱动对应的服务名称为cellular_radio1，那么telephony_core_service通过HDF与RIL进行通信肯定会调用到该服务名称，因此无查找telephony_core_service的相关代码，可以很快定位到telephony_core_service/services/tel_ril/src/tel_ril_manager.cpp该代码，该代码中有一个关键类TelRilManager，它用来负责管理tel_ril。

       看tel_ril_manager.cpp中的一个关键函数ConnectRilAdapterService，它就是用来通过HDF框架获取RIL_ADAPTER的服务，之前定义过RIL_ADAPTER_SERVICE_NAME常量为"cellular_radio1"，它就是在vendor_hisilicon/XXXX/hdf_config/uhdf/device_info.hcs中配置的hril_hdf驱动对应的服务名称。