Learning on chengzhycn's blog

Envoy Go HTTP Filter

Tue, 28 Apr 2026 15:18:28 +0800

Go HTTP 过滤器 (envoy.filters.http.golang) 允许使用 Go 编写 Envoy HTTP 过滤器。Go 代码被编译为共享库 (.so)，在运行时通过 dlopen 加载，并借由 CGo bridge 集成到 Envoy 的 C++ 过滤器链中。

架构

Go HTTP Filter 主要分为两端：

C++ 端：负责 DSO 加载、过滤器链集成以及线程安全。
Go 端：通过 Go SDK 实现过滤器逻辑，通过 CGo 与 C++ 通信。

ABI 边界由 contrib/golang/common/go/api/api.h 中的共享 C 结构体定义。

DSO (动态共享对象) 加载机制

Go HTTP 过滤器通过 contrib/golang/common/dso/ 中定义的专用 DSO 机制加载 Go 编译的共享库。这与 Envoy 核心扩展中的 dynamic_modules 是两套独立的实现。

核心组件

1. DSO 管理器 (DsoManager)

DsoManager 类 (contrib/golang/common/dso/dso.h) 负责管理共享库的生命周期：

nano-vllm 代码流程

Tue, 27 Jan 2026 09:18:28 +0800

整体架构图

┌─────────────────────────────────────────────────────────────────┐
│                         用户入口层                               │
│  example.py → LLM.generate() → add_request() + step() 循环      │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         引擎层 (Engine)                          │
│  ┌─────────────┐   ┌─────────────┐   ┌──────────────────┐      │
│  │  Scheduler  │ → │ ModelRunner │ → │  BlockManager    │      │
│  │  (调度器)    │   │ (模型执行器) │   │  (KV Cache管理)  │      │
│  └─────────────┘   └─────────────┘   └──────────────────┘      │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         模型层 (Models)                          │
│  Qwen3ForCausalLM → Qwen3Model → [Qwen3DecoderLayer x N]       │
└─────────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│                         算子层 (Layers)                          │
│  Attention │ Linear │ LayerNorm │ RoPE │ Activation │ Sampler  │
└─────────────────────────────────────────────────────────────────┘

推理服务流程详解

阶段 1: 初始化阶段

# example.py
llm = LLM(path, enforce_eager=True, tensor_parallel_size=1)

调用链：

KubeCon North America 2025 Review

Sun, 23 Nov 2025 15:18:28 +0800

KubeCon North America 2025 13号结束了，官网上也有了些会议资料。挑了几个感兴趣的话题总结下。

Dynamic Routing with Multi-Cluster Inference Gateway

https://kccncna2025.sched.com/event/27FeP/ai-inference-without-boundaries-dynamic-routing-with-multi-cluster-inference-gateway-rob-scott-google-daneyon-hansen-soloio?iframe=no&w=100%&sidebar=yes&bg=no

这段时间正好在做 AI 网关，这个话题可以说是“瞌睡了送枕头”。

推理服务和传统 API 流量相比，在 payload，响应时间，后端资源开销上都有着很大的差异（见下图）。

因此，推理网关需要做到后端负载感知的调度（传统 API 网关也有类似的方案，尤其是在后端机型不一样，普通的 rr 无法均匀负载时，做后端负载感知动态调权）。在 Gateway 和推理实例间引入了一个 EPP（Endpoint Picker）组件（注：EPP 现在也是 Kubernetes 做推理服务的一个通用组件），采集推理实例的指标来动态选择推理后端。

benchmark 数据显示，使用推理网关相比传统负载均衡，推理实例间的负载更加均衡，请求排队更少，从而降低了响应时间。

在多集群场景下，这套方案需要解决 3 个问题：

服务发现：Cluster Inference Services 如何暴露给 Gateway？
后端选择：Gateway 如何在多集群间分配流量？
路由模式：流量如何从 Gateway 转发到集群？

第一个问题作者提了 3 个解决方法：

不是关注重点，略过。

第二个问题，简单的 RR 和 Active-Passive 肯定就失去了推理网关负载感知的优势。所以，在 EPP 感知负载之外，Gateway 也得做负载感知。作者也提了两个方法：

从层级上来说，EPP Aggregate Metrics 方案更加简洁，毕竟在 EPP 上还得做二次调度。

最后一个问题，如果 EPP 能跨集群直接访问，direct routing 是最合适的方式，不行的话再加一层网关，使用 Cluster-Local Gateway 做暴露也能访问。

网关的限流方案

Sun, 16 Nov 2025 15:18:28 +0800

Note：本文由 Google Gemini DeepResearch 生成。

1.网关限流服务的战略必要性与流量控制架构

1.1. 网关在流量管理中的控制点角色与核心必要性

API 网关在现代微服务架构中扮演着至关重要的流量控制点角色，负责管理北向（Ingress）和南向（Egress）的流量。对流量实施限制（即限流）是保障上游服务稳定性、维持系统可用性和实现资源公平分配的核心防御机制。

限流服务的战略必要性主要体现在以下几个方面：

首先，限流是防止系统过载和雪崩效应的关键。当面临突发流量高峰时，如不加限制，后台服务器可能因资源耗尽而被压垮。通过限制客户端在指定时间窗内的请求次数，网关可以有效地保护应用编程接口（API）及其背后的微服务。其次，限流是抵御恶意攻击的有效手段，尤其是分布式拒绝服务攻击（DDoS）或防止未受限制的网络爬虫过度消耗计算资源。如果任由客户端无限制地访问上游服务，系统的可用性将受到负面影响。

从架构设计的角度看，网关作为请求进入系统的唯一入口，是实施全局限流策略的最佳位置，可以根据 IP、API 密钥、特定消费者（Consumer）或其他定制标准来应用限流规则。

1.2. 限流策略的粒度、层次结构与定制化响应

在实际应用中，灵活的限流服务需要支持精细的粒度和层次化配置模型，以满足不同业务和资源保护的需求。这种配置的优先级机制体现了一种 “微观精确控制”优于“宏观默认保护” 的设计哲学。

网关通常支持多层次的限流配置，包括：

特定 API 或消费者限流： 这是优先级最高的限流配置。例如，用户可以对单个关键 API 进行限流设置，或者对特定的消费者群体施加限制。这种配置会覆盖所有默认设置。这意味着在限流值冲突时，系统优先执行最明确定义或最严格的限制，确保关键资源的防护级别不受宏观策略的稀释。
API 默认限流： 作用于应用下大部分 API 的通用配置。当没有针对单个 API 配置限流值时，将采用此默认值。
应用总限流 (App Total Limit)： 这是对当前应用下所有 API 请求的总和设置的上限。应用总限流是防止资源被“虹吸”的最后防线。即使单个 API 的限流都没有达到，一旦应用的总请求量超出限流总和值，所有请求都将被限制。这种设计解决了在微服务架构中，攻击者通过对大量低 QPS API 进行频繁调用，最终耗尽整个应用共享资源预算的“长尾攻击”问题。

网关在触发限流时，必须向客户端返回明确的、用户友好的响应。例如，默认的限流响应可能包含 {"resultStatus":1002, "tips":"顾客太多，客官请稍候"} 。为了实现友好的降级体验，网关需要支持定制化的响应格式，允许用户配置 JSON 格式的返回内容，如通过 resultStatus 字段（例如，1002 表示限流）和 tips 字段向用户提供定制化的限流提示。

2. 常见限流算法的原理、适用性与分布式性能剖析

选择合适的限流算法是构建高性能网关服务的基石。不同的算法在精确度、突发处理能力和分布式系统中的扩展性方面存在显著差异。

2.1. 固定窗口计数器 (Fixed Window Counter, FWC)

固定窗口计数器是最简单、资源消耗最低的限流算法。它在一个固定的时间周期内（例如每 60 秒）累积请求计数，当周期结束时，计数器重置。

优势与局限性： FWC 的实现非常简单，查询和递增操作计算复杂度为 $O(1)$，因此延迟极低。然而，其主要局限在于边界突发问题。如果客户端在窗口结束前的一刻发出大量请求，并在下一个窗口开始后的第一时间再次发出同等量的请求，系统在短时间内实际放行的请求量可能高达阈值的两倍。这使得 FWC 难以应对流量的瞬间爆发，可能导致上游服务过载。

常见的大模型 OpenAPI 规范

Wed, 05 Nov 2025 21:18:28 +0800

AI Gateway 的对接开发中，一个重要的内容就是对接不同厂商推理服务的接口协议。目前，推理服务的接口协议主要分为以下几种类型：

文本对话接口，如 OpenAI 的 chat completions 和 response API 等
向量接口，向量接口用于将输入的文本或者图片、视频（多模态）等转换成向量表示，适用于搜索（文搜图、图搜图、图文混合搜索）、聚类、推荐等场景。

文本对话

文本对话 API 需要提供如下能力支持：

模型选择
用户、系统、模型输入内容角色区分
模型参数调整
工具调用
MCP 支持
用量统计

目前使用最广泛的文本对话接口自然是 OpenAI 的 chat completions API。几乎所有的 LLM 服务提供商都支持 chat completions compatible 调用。

https://platform.openai.com/docs/api-reference/introduction

chat completions

基本调用：

curl https://api.openai.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-5",
    "messages": [
      {
        "role": "developer",
        "content": "You are a helpful assistant."
      },
      {
        "role": "user",
        "content": "Hello!"
      }
    ]
  }'

model: 请求调用的模型
messages：构成对话的消息体。根据消息的来源角色，message 可以分为 developer/system（开发者，系统提供的 prompt），user（用户自身的输入）和 assistant（模型的响应，用于多轮对话时模型的上下文传递）。
- content 分为两种类型，纯文本即为 string，非纯文本 content 为列表类型，内容根据 type（text，image_url，input_audio 等）有不同的字段
stream：采用正常 HTTP 响应还是 sse 响应
stream_options: 在 sse 响应时，有些模型默认不会输出 usage 信息，需要显式将 stream_options.include_usage 设置成 true
temperature：模型温度，取值范围 0 - 2，值越高，输出的 tokens 随机性越大
top_p：和 tempreature 一样对模型输出进行调整的参数，模型会考虑概率质量最高的top_p个tokens的结果。所以0.1意味着只考虑概率质量最高的10%的tokens。
reasoning_effort：模型的推理深度，比如对于 OpenAI 模型来说有 minimal，low，medium，high 等多种选择。
max_completion_tokens：最大输出 tokens 数，包括 output tokens 和 reasoning tokens。替代原来的 max_tokens 字段。
tools：告知大模型本地可调用的工具列表。工具里面定义了工具的名称、描述和 json schema 表示的参数描述。替代原来的 functions 字段。
tool_choice：告知模型对于工具的调用选择。none 表示不要调用任何工具直接生成 messages，auto 表示由模型自己决定是否调用 allowed_tools。required 表示模型必须调用至少一个工具。

除此之外，各家可以在 OpenAI 标准的 API 上扩展自己的字段，比如 cherry studio 会使用 thinking 字段来开启/关闭模型思考：

APISIX 插件体系

Thu, 30 Oct 2025 12:18:28 +0800

背景知识

APISIX 基于 Openresty 和 Nginx 开发，了解 APISIX 的插件体系也有必要先了解下 Nginx 和 Openresty 的基础知识。

Nginx 请求处理阶段

Nginx 将一个 HTTP 请求的处理过程精心划分为一系列有序的阶段（Phases），就像一个工厂的流水线。每个阶段都有特定的任务，不同的模块可以将自己的处理程序（handler）注册到感兴趣的阶段。这种设计使得 Nginx 的功能高度模块化、可扩展，并且处理流程非常清晰高效。

一个请求在 Nginx 中主要会经过以下 11 个处理阶段：

1. `NGX_HTTP_POST_READ_PHASE` (请求读取后阶段)

任务: 接收到完整的请求头（Request Header）之后，第一个被执行的阶段。
常用模块: ngx_http_realip_module。
作用举例: 在这个阶段，realip 模块会根据 X-Forwarded-For 或 X-Real-IP 等请求头，将客户端的真实 IP 地址替换掉代理服务器的 IP 地址。这对后续的访问控制和日志记录至关重要。

2. `NGX_HTTP_SERVER_REWRITE_PHASE` (Server 级别地址重写阶段)

任务: 在 server 配置块中执行 URL 重写。
常用模块/指令: rewrite 指令（当它定义在 server 块中时）。
作用举例: 在请求进入具体的 location 匹配之前，对 URL 进行全局的、初步的改写。例如，将所有 http 请求强制重定向到 https。

server {
    listen 80;
    server_name example.com;
    # 这个 rewrite 就工作在 SERVER_REWRITE 阶段
    rewrite ^/(.*)$ https://example.com/$1 permanent; 
}

3. `NGX_HTTP_FIND_CONFIG_PHASE` (配置查找阶段)

任务: 根据上个阶段处理完的 URI，查找并匹配对应的 location 配置块。
核心功能: 这是 Nginx 路由的核心。Nginx 会用请求的 URI 与 location 指令定义的规则进行匹配，找到最合适的 location。这个阶段没有模块可以注册 handler，是 Nginx 核心自己完成的。

4. `NGX_HTTP_REWRITE_PHASE` (Location 级别地址重写阶段)

任务: 在上一步匹配到的 location 块内部，执行 URL 重写。
常用模块/指令: rewrite 指令（当它定义在 location 块中时）、set 指令。
作用举例: 对特定 location 的请求进行更精细的 URL 改写。这个阶段的 rewrite 可能会导致 Nginx 重新回到 FIND_CONFIG 阶段去匹配新的 location，可能会有循环，最多执行 10 次以防止死循环。

location /app/ {
    # 这个 rewrite 工作在 REWRITE 阶段
    rewrite ^/app/(.*)$ /v2/app/$1 break; 
}

5. `NGX_HTTP_POST_REWRITE_PHASE` (地址重写后阶段)

任务: 防止 rewrite 阶段的重写指令导致死循环。如果 URI 在上一个阶段被重写，这个阶段会把重写后的 URI 交给 Nginx，让其重新开始 FIND_CONFIG 阶段，查找新的 location。这是一个内部阶段，用户通常不直接感知。

6. `NGX_HTTP_PREACCESS_PHASE` (访问权限控制前置阶段)

任务: 在正式的访问权限检查之前，做一些准备工作。
常用模块: ngx_http_limit_conn_module (连接数限制), ngx_http_limit_req_module (请求速率限制)。
作用举例: 在检查用户名密码之前，先检查客户端的请求速率是否过快，如果过快，直接拒绝，不必再执行后面的阶段。

7. `NGX_HTTP_ACCESS_PHASE` (访问权限控制阶段)

任务: 对请求进行权限验证。
常用模块/指令: ngx_http_access_module (allow, deny), ngx_http_auth_basic_module (HTTP 基本认证)。
作用举例: 检查客户端 IP 是否在允许列表中，或者验证用户提供的用户名和密码是否正确。如果这个阶段有任何模块拒绝了请求，处理就会立即中断并返回错误（如 403 Forbidden）。

8. `NGX_HTTP_POST_ACCESS_PHASE` (访问权限控制后置阶段)

任务: 主要用于配合 ACCESS 阶段的 satisfy 指令。
作用举例: 当 satisfy any; 被使用时，如果 ACCESS 阶段有模块允许了访问（例如 IP 匹配成功），POST_ACCESS 阶段的处理就可以被跳过。如果 ACCESS 阶段没有明确允许，这个阶段的处理（例如 HTTP 基本认证）就会被执行。

9. `NGX_HTTP_TRY_FILES_PHASE` (Try_files 阶段)

任务: try_files 指令专属的特殊阶段。
常用模块/指令: try_files。
作用举例: 按顺序检查文件或目录是否存在，如果找到，则内部重定向到该文件，如果都找不到，则执行最后一个参数（通常是内部重定向到一个 location 或返回一个状态码）。

location / {
    # 这个指令工作在 TRY_FILES 阶段
    try_files $uri $uri/ /index.html;
}

10. `NGX_HTTP_CONTENT_PHASE` (内容生成阶段)

任务: 核心阶段，负责生成最终的响应内容并发送给客户端。
重要特性: 每个 location 只有一个模块能成为“内容处理模块”（Content Handler）。
常用模块:
- ngx_http_static_module: 处理静态文件。
- ngx_http_proxy_module: 将请求反向代理到后端服务器 (proxy_pass)。
- ngx_http_fastcgi_module: 将请求转发给 FastCGI 应用（如 PHP-FPM）。
- ngx_http_index_module: 处理目录索引文件。
- return: 直接返回指定的状态码或内容。
执行逻辑: Nginx 会调用在 location 中找到的内容处理模块。例如，如果配置了 proxy_pass，那么 proxy_module 就会接管请求。如果没有特定的内容处理模块，默认会由 static_module 尝试提供静态文件服务。

11. `NGX_HTTP_LOG_PHASE` (日志记录阶段)

任务: 请求处理完成后，记录访问日志。
常用模块/指令: ngx_http_log_module (access_log)。
作用举-例: 无论请求成功还是失败，这个阶段都会被执行（除非有严重错误），用于将请求的相关信息（如客户端IP、请求时间、状态码等）写入到日志文件中。

过滤器模块 (Filter Modules)

当 CONTENT 阶段生成了响应内容后，在发送给客户端之前，响应数据还会经过一系列的 过滤器（Filter） 链处理。过滤器负责对响应头和响应体进行修改或加工。

WebSocket Origin Header 校验失败

Tue, 21 Oct 2025 15:18:28 +0800

最近做 APISIX 线上服务时遇到一个场景：业务使用 websocket 转发时，在浏览器会出现 WebSocket close with status code 1006 的错误。打开调试工具查看发现在 websocket 握手时服务端返回了 403。

非常奇怪的是，如果业务不经过 APISIX 直接访问后端 code-server 是没有问题的（中间也得经过一层 Ingress 转发）。

简单的流量模型如下：

                                                                                                                      
                                                                                                                      
                               +--------------+                              +--------------+          +-------------+
  https://domain.com:9443/xxx  |              |  http://domain.com:23480/xxx |              |          |             |
--------------------------------   APISIX     -------------------------------+   Ingress    -----------+ code-server |
                               |              |                              |              |          |             |
                               +--------------+                              +--------------+          +-------------+

经过对比发现，两者的请求头里面 Host 和 Origin 是存在差异的。尝试在 APISIX 中强制修改 Host 头部，问题没有解决。然后利用 proxy-rewrite 强制修改 Origin 头部，请求恢复正常。

    "plugins": {
      "proxy-rewrite": {
        "uri": "/anything",
        "headers": {
          "set": {
	        "Origin": "http://domain.com"
          }
        }
      }
    },

那么问题来了，为什么改完 Origin Header 就行了？code-server 是如何处理 Origin Header 的？为什么 Ingress 可以，APISIX 不行？

Introducing Kubernetes Gateway API

Thu, 16 Oct 2025 16:18:28 +0800

Kubernetes Gateway API 是一个由 SIG-Network 孵化和维护的 开放、标准、可扩展的 API，旨在为 Kubernetes 集群内部和外部的统一流量管理提供更强大、更灵活、更具表现力的方式。

它被视为 Ingress API 的继任者和演进，解决了 Ingress 在灵活性、可扩展性、角色分离和 L4-L7 支持方面的诸多局限性。Gateway API 不仅仅关注 HTTP 流量，还支持 TCP、UDP 以及 TLS 路由，覆盖了更广泛的网络场景。

为什么需要 Gateway API

在 Gateway API 出现之前，Kubernetes 主要使用 Ingress 来管理集群的 L7 HTTP/HTTPS 流量。然而，Ingress 存在一些固有的局限性，促使了 Gateway API 的诞生：

功能有限： Ingress 本身功能非常基础，只支持主机和路径路由。任何高级功能（如流量拆分、重写、限速、认证等）都必须通过特定于 Ingress 控制器（如 NGINX Ingress, Traefik, AWS ALB Ingress 等）的 注解（Annotations） 来实现。
可移植性差： 注解是特定于实现的，这意味着用 NGINX Ingress 注解编写的规则无法直接移植到 Traefik 或其他 Ingress 控制器上，造成供应商锁定。
缺乏角色分离： Ingress 资源将网络基础设施的配置（例如暴露的端口、TLS 证书）与应用程序的路由规则混在一起，这使得集群管理员和应用开发者之间的职责难以清晰划分。
L4 流量支持不足： Ingress 仅专注于 HTTP/HTTPS (L7) 流量。对于 TCP、UDP 或 TLS 直通（Passthrough）等 L4 流量，通常需要使用 LoadBalancer 类型的 Service 或其他的解决方案。
表达能力有限： 难以表达复杂的路由策略，如基于请求头、查询参数的匹配，细粒度的流量权重分配等。

Gateway API 旨在解决这些问题，提供一个更加健壮和通用的流量管理框架。

Go 汇编分析

Wed, 17 Sep 2025 21:45:28 +0800

Go的汇编不是像 C/C++ 一样，对机器码的直接描述，而是兼容跨平台需求实现的半抽象化的指令集。

https://go.dev/doc/asm

汇编分析（Go 1.17）

我们用一个简单的例子来开始汇编分析：

package main

func main() {
	add(1, 3)
}

func add(i, j int) int {
	return i + j
}

汇编结果，删去了一些无关的输出：

# go tool compile -S -l -N main.go
"".main STEXT size=54 args=0x0 locals=0x18 funcid=0x0
        0x0000 00000 (main.go:3)        TEXT    "".main(SB), ABIInternal, $24-0
        0x0000 00000 (main.go:3)        CMPQ    SP, 16(R14)
        0x0004 00004 (main.go:3)        PCDATA  $0, $-2
        0x0004 00004 (main.go:3)        JLS     47
        0x0006 00006 (main.go:3)        PCDATA  $0, $-1
        0x0006 00006 (main.go:3)        SUBQ    $24, SP
        0x000a 00010 (main.go:3)        MOVQ    BP, 16(SP)
        0x000f 00015 (main.go:3)        LEAQ    16(SP), BP
        0x0014 00020 (main.go:3)        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0014 00020 (main.go:3)        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x0014 00020 (main.go:4)        MOVL    $1, AX
        0x0019 00025 (main.go:4)        MOVL    $3, BX
        0x001e 00030 (main.go:4)        PCDATA  $1, $0
        0x001e 00030 (main.go:4)        NOP
        0x0020 00032 (main.go:4)        CALL    "".add(SB)
        0x0025 00037 (main.go:5)        MOVQ    16(SP), BP
        0x002a 00042 (main.go:5)        ADDQ    $24, SP
        0x002e 00046 (main.go:5)        RET
        0x002f 00047 (main.go:5)        NOP
        0x002f 00047 (main.go:3)        PCDATA  $1, $-1
        0x002f 00047 (main.go:3)        PCDATA  $0, $-2
        0x002f 00047 (main.go:3)        CALL    runtime.morestack_noctxt(SB)
        0x0034 00052 (main.go:3)        PCDATA  $0, $-1
        0x0034 00052 (main.go:3)        JMP     0

"".add STEXT nosplit size=56 args=0x10 locals=0x10 funcid=0x0
        0x0000 00000 (main.go:7)        TEXT    "".add(SB), NOSPLIT|ABIInternal, $16-16
        0x0000 00000 (main.go:7)        SUBQ    $16, SP
        0x0004 00004 (main.go:7)        MOVQ    BP, 8(SP)
        0x0009 00009 (main.go:7)        LEAQ    8(SP), BP
        0x000e 00014 (main.go:7)        FUNCDATA        $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x000e 00014 (main.go:7)        FUNCDATA        $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
        0x000e 00014 (main.go:7)        FUNCDATA        $5, "".add.arginfo1(SB)
        0x000e 00014 (main.go:7)        MOVQ    AX, "".i+24(SP)
        0x0013 00019 (main.go:7)        MOVQ    BX, "".j+32(SP)
        0x0018 00024 (main.go:7)        MOVQ    $0, "".~r2(SP)
        0x0020 00032 (main.go:8)        MOVQ    "".i+24(SP), AX
        0x0025 00037 (main.go:8)        ADDQ    "".j+32(SP), AX
        0x002a 00042 (main.go:8)        MOVQ    AX, "".~r2(SP)
        0x002e 00046 (main.go:8)        MOVQ    8(SP), BP
        0x0033 00051 (main.go:8)        ADDQ    $16, SP
        0x0037 00055 (main.go:8)        RET

FUNCDATA和PCDATA是由编译器引入的，主要包含垃圾回收时使用的信息，这里略过。

Lua：Table 浅析

Sun, 14 Sep 2025 23:45:28 +0800

本文的分析基于 OpenResty 的 Lua 分支（https://github.com/openresty/luajit2）。

核心 API

table 的 API 定义在 src/lib_table.c 中，API 分为三个部分：

标准库函数：

table.insert() - 向 table 插入元素
table.remove() - 移除 table 元素
table.concat() - 连接 table 元素为字符串
table.sort() - 对 table 进行排序
table.maxn() - 找到 table 中最大数字键
table.move() - 移动 table 元素

LuaJIT 扩展函数：

table.new() - 预分配指定大小的 table

OpenResty 扩展函数：

table.clear() - 清空 table 内容
table.clone() - 克隆 table
table.nkeys() - 获取 table 键的数量
table.isarray() - 检查是否为数组
table.isempty() - 检查 table 是否为空

数据结构

typedef struct Node {
  TValue val;         // 值对象，必须是第一个字段
  TValue key;         // 键对象
  MRef next;          // 哈希链指针
#if !LJ_GC64
  MRef freetop;       // 32位架构下的空闲节点顶部指针(存储在node[0])
#endif
} Node;

typedef struct GCtab {
  GCHeader;           // GC 通用头部：nextgc, marked, gct
  uint8_t nomm;       // 元方法负缓存掩码
  int8_t colo;        // 数组共址标记 (-1表示已分离, >0表示共址大小)
  MRef array;         // 数组部分指针
  GCRef gclist;       // GC 链表指针
  GCRef metatable;    // 元表引用
  MRef node;          // 哈希部分指针
  uint32_t asize;     // 数组部分大小 [0, asize-1]
  uint32_t hmask;     // 哈希掩码 (哈希部分大小-1)
#if LJ_GC64
  MRef freetop;       // 64位架构下的空闲节点顶部指针
#endif
} GCtab;

可以看到，GCtab 中同时定义了数组部分 array 和哈希部分 node。

Lua：Concurrency

Mon, 01 Sep 2025 00:27:09 +0800

Lua 的并发（Concurrency）设计核心在于其轻量级、嵌入式的哲学，以及对协作式多任务的首选。它通过强大的协程机制实现并发，但本身不提供多线程/多进程的并行能力。

多线程/多进程

核心语言无内置支持： Lua 语言本身的核心 VM 被设计为单线程执行。它不提供内置的语法或标准库来直接创建和管理线程（std::thread）或进程（fork）。
独立的 Lua State： 一个 Lua VM 实例被称为一个“Lua State”。每个 Lua State 是完全独立的运行时环境，拥有自己的全局变量、栈、打开的文件、垃圾回收器等。它们之间默认不共享任何数据。
宿主语言的责任： 如果需要在 Lua 中实现真正的并行（多核利用），必须依赖于宿主语言（如 C/C++）的多线程/多进程机制。
- 实现方式： 在宿主语言的每个线程或进程中，创建并运行一个独立的 Lua State。
- 数据交换： 这些独立的 Lua State 之间无法直接共享内存。数据交换必须通过宿主语言提供的进程间通信 (IPC) 或线程间通信 (ITC) 机制（如消息队列、共享内存、管道、套接字等）来完成。
- 优点： 简单安全，因为 Lua State 之间是隔离的，避免了复杂的并发同步问题。
- 缺点： 额外的通信开销和复杂性，且无法在单个 Lua State 内部实现并行。
第三方库（封装）： 存在一些第三方库（如 LuaLanes）试图提供在 Lua 中模拟多线程/多进程的 API。这些库通常是在底层创建独立的 Lua State，并封装了 IPC 机制，方便 Lua 开发者使用，但其本质仍然是基于宿主语言的底层能力和独立的 Lua State。

协程

协程的设计与实现

设计理念： Lua 协程是为了提供协作式多任务 (Cooperative Multitasking) 而设计。它们允许在单个线程中实现任务的暂停和恢复，以模拟并发，而无需复杂的锁机制。
“有栈协程” (Stackful Coroutines)： Lua 协程是有栈的。这里的“栈”指的不是操作系统的 C 语言栈，而是 Lua 虚拟机内部维护的Lua VM 栈。
- Lua VM 栈： 每个协程在创建时都会分配一个独立的 Lua VM 栈（或在需要时动态扩展）。这个栈存储着协程的局部变量、函数参数、中间表达式结果和函数调用上下文。
实现机制：
- coroutine.create(function)： 创建一个新的协程（一个thread类型的值），但并不立即执行。它会分配并初始化一个新的 Lua VM 栈。
- coroutine.yield(...) (保存栈)： 当一个协程调用 yield 时，Lua VM 会：
  1. 保存当前 Lua VM 栈的完整状态（包括所有活跃的栈帧、局部变量值、程序计数器等）。这些信息会被存储在协程对象本身（在堆上分配）中。
  2. 暂停当前协程的执行。
  3. 将控制权返回给调用 coroutine.resume 的那个协程或主线程。 C 语言栈会正常展开，yield 作为一个 C 函数正常返回。
- coroutine.resume(co, ...) (恢复栈)： 当一个协程被 resume 时，Lua VM 会：
  1. 从协程对象中加载并恢复其之前保存的 Lua VM 栈状态。 这包括设置栈顶指针、恢复所有栈帧和程序计数器，使得协程能够从上次 yield 的点继续执行。
  2. 将控制权转移给被恢复的协程。 C 语言栈上会为 resume 函数创建一个新的栈帧，并在其中运行被恢复的 Lua 协程。
优点： 简单、高效、避免了与 OS 栈相关的复杂性，并且由于是协作式的，没有竞态条件和锁的开销。
缺点： 无法利用多核 CPU。

协程示例：

Lua - An Overview

Sun, 31 Aug 2025 13:29:48 +0800

Lua 和 LuaJIT

Lua

Lua 是一个开源项目，由巴西里约热内卢天主教大学的 Roberto Ierusalimschy、Luiz Henrique de Figueiredo 和 Waldemar Celes 创建。它的版本控制相对简单明了。

Lua 的版本体系

Lua 的版本号通常是 X.Y 的形式，例如 5.1, 5.2, 5.3, 5.4。

X (主版本号/Major Version): 表示一个重大更新，通常会引入不兼容的更改（breaking changes），新的核心特性，或者对虚拟机架构的显著改进。从 5.x 到 5.y，y 增加通常意味着语法、API 或语义的更改，可能需要修改现有代码。
- 例子:
  - Lua 5.0: 引入了协程 (coroutines)。
  - Lua 5.1: 引入了模块系统 (module system)、vararg 参数的改进。
  - Lua 5.2: 引入了 goto 语句、环境 (environments) 的重新设计、新的 _ENV 上值。
  - Lua 5.3: 引入了整数类型、位操作 (bitwise operations)、UTF-8 支持。
  - Lua 5.4: 引入了新的垃圾回收器、弱表 (weak tables) 的改进。
Y (次版本号/Minor Version) 或补丁版本 (Patch Version): 在主版本中，通常用于表示错误修复、性能优化或次要的功能增强。这些更改通常是向后兼容的（backward compatible），不会破坏现有代码运行。有时候，一个版本号会是 X.Y.Z 的形式，Z 就代表补丁版本。
- 例子: Lua 5.3.1, Lua 5.3.2, Lua 5.3.3 等等。这些通常是修复 bug。

LuaJIT

https://github.com/LuaJIT/LuaJIT

Wasm Internals: Stack Machine

Wed, 20 Aug 2025 01:04:28 +0800

Wasm 中的“栈机”（Stack Machine），这正是其核心执行模型之一。Wasm 是一种基于栈的虚拟机，这意味着它的所有操作都通过从一个操作数栈中弹出值、执行操作并将结果压回栈中来完成。它没有传统的“寄存器”概念。

什么是栈机？

在计算机科学中，栈机是一种计算模型，其中指令操作数被隐含地从一个被称为“操作数栈”的内存区域中获取，并且结果被隐含地压回这个栈。这种模型与基于寄存器或基于累加器的模型形成对比。

Wasm 栈机的工作原理

Wasm 模块中的函数是由一系列指令组成的。这些指令会操作一个中央的操作数栈。

操作数栈（Operand Stack）：
- 这是 Wasm 执行函数时最核心的数据结构。
- 所有的操作数（如整数、浮点数）和操作结果都临时存储在这个栈上。
- 指令不会像在注册机中那样直接指定操作数的位置（如“将 R1 的值加到 R2”）。相反，它们会假定操作数已经在栈的顶部。
局部变量（Local Variables）：
- 除了操作数栈，每个函数调用还有一个独立的“局部变量”区域。
- 局部变量是命名的存储位置，可以在函数的整个执行过程中被访问和修改。
- 虽然局部变量不是栈的一部分，但有很多指令允许你将局部变量的值压入栈中，或者将栈顶部的值存储到局部变量中。
参数（Parameters）：
- 函数的参数在函数被调用时，会被初始化为局部变量的一部分（通常是前几个局部变量）。
- 它们也可以被认为是函数执行上下文的一部分。
指令的操作：
- 压栈（Push）：很多指令会将值压入栈中。例如：
  - i32.const 42：将整数常量 42 压入栈。
  - local.get <idx>：获取索引为 <idx> 的局部变量的值并压入栈。
- 弹栈（Pop）：大多数操作指令会从栈顶弹出所需数量的操作数。例如：
  - i32.add：弹出栈顶的两个 i32 整数，将它们相加，然后将结果压回栈。
  - if/else/loop 等控制流指令的条件值也会从栈中弹出。
- 复合操作：一些指令可能弹出一个值，执行一些副作用（如内存写入），而不压入任何新值。例如：
  - i32.store：弹出内存地址和要存储的值，将值写入内存。

栈机模型的优势与特点

紧凑性（Compactness）：
- 指令更短，因为它们不需要编码操作数的位置。例如，一个加法操作，在寄存器机中可能需要指定两个源寄存器和一个目标寄存器；在栈机中，它只是一个简单的 add 指令。
- 这有助于生成更小的二进制代码，对于 Web 环境中的快速下载和解析非常有利。
简化编译器后端（Simplified Compiler Backends）：
- IR（中间表示）到指令的映射通常更直接。许多高级语言的语义本身就可以很容易地映射到栈操作。
- 这使得将 C/C++/Rust 等语言编译到 Wasm 变得相对容易。
易于验证（Easy to Validate）：
- Wasm 在加载时会进行严格的类型检查和结构验证。栈机模型使得验证其类型安全变得相对容易。例如，当检查 i32.add 指令时，验证器只需确保栈顶有两个 i32 类型的值。
- 这对于沙盒环境中的安全性至关重要。
独立于目标架构（Architecture-Independent）：

Kubernetes CSI 简介

Tue, 24 Jun 2025 09:57:28 +0800

K8s CSI 是 Kubernetes 中非常重要的一个组件，它解决了存储与计算分离的复杂性，并为容器化应用提供了持久化存储的能力。

1. 基本概念

CSI (Container Storage Interface) 译为 容器存储接口。它是由 Kubernetes 社区与存储厂商共同制定的一套标准接口规范。

在 CSI 出现之前，Kubernetes 存储插件的开发和管理存在以下痛点：

紧耦合问题： Kubernetes 内部集成了大量的存储驱动（In-tree 存储插件），例如 AWS EBS、GCE PD、Azure Disk、Ceph RBD 等。这意味着每当存储厂商需要支持 Kubernetes 时，他们都必须将其存储驱动代码提交到 Kubernetes 的核心代码库中。这种方式导致了：
- Kubernetes 代码库臃肿： 集成了大量存储逻辑，增加了核心代码的复杂性和维护难度。
- 发布周期长： 存储驱动的更新需要跟随 Kubernetes 的发布周期，新功能和 bug 修复不能及时推送到用户。
- 存储厂商开发受限： 每次更新都需要与 Kubernetes 社区协调，开发和测试流程繁琐。
兼容性问题： 不同存储厂商的存储系统差异巨大，缺乏统一的接口规范，导致存储系统与 Kubernetes 之间的集成困难。

CSI 的目标就是解决这些问题，实现存储系统与 Kubernetes 的解耦。 它定义了一套通用的接口，允许任何存储厂商开发自己的 CSI 驱动，然后通过这些驱动来与 Kubernetes 进行交互，从而为容器提供存储服务。

1.1. 资源定义

1.1.1. Volumes

Volumes 是 Kubernetes 中 Pod 通过文件系统访问和共享数据的抽象。它主要提供了如下功能：

通过 ConfigMap 或者 Secret 共享配置；
跨容器、跨 Pod 甚至跨 Node 共享数据；
数据持久化。在 Pod 销毁之后仍能继续访问数据。对于 Pod 来说，Volumes 通过 .spec.volumes 提供给 Pod，容器通过 .spec.containers[*].volumeMounts 来将指定 Volumes 挂载到指定目录。

1.1.2. Persistent Volumes 和 Persistent Volumes Claim

PV 和 PVC 提供了两套 API 将存储的提供和消费分离。

VRF: An Overview

Fri, 25 Apr 2025 20:30:28 +0800

什么是 VRF（virtual routing forwarding）

VRF是一种实现三层网络隔离的关键技术。它通过创建多个路由表，为不同的网络流量提供独立的转发路径。 这意味着，任何三层网络结构，如接口的IP地址、静态路由的配置，甚至BGP（边界网关协议）会话，都可以被映射到特定的VRF中。这种映射机制就像是为每个VRF构建了一个独立的网络空间，彼此之间相互隔离，极大地增强了网络的安全性和管理的便利性。在MPLS VPN（多协议标签交换虚拟专用网络）等应用场景中，VRF为实现大规模的网络隔离和灵活的路由策略提供了基础框架。就像 VLAN 隔离了二层网络一样，VRF 隔离了三层网络。

为什么需要 VRF

在 VRF 出现之前，Linux 用户主要采用两种方式来尝试实现类似的功能：策略路由（policy routing）和网络命名空间（net namespace）。然而，这两种方法都存在明显的局限性。

策略路由虽然能够通过多个路由表和策略规则来模拟 VRF 的部分功能（事实上，在 Linux 中，也是基于策略路由来去对 VRF 做的实现），但它的缺点十分突出。这种方式在配置和管理上非常复杂，难以确保网络隔离的有效性，在面对严格的网络审计时，往往无法通过。其复杂性不仅增加了运维的难度，还可能导致网络故障的风险上升，因此不被推荐使用。

网络命名空间在容器技术兴起后得到了广泛应用，它能够为容器提供全面的网络隔离。但在模拟 VRF 功能时，却显得有些“大材小用”。网络命名空间会对所有网络相关的资源进行完全隔离，包括设备、接口、ARP 表和路由表等。这意味着，即使是一些不需要隔离的服务，也会被隔离在不同的命名空间中。以 LLDP（链路层发现协议）为例，在使用网络命名空间的情况下，若要在不同的网络隔离环境中使用 LLDP，就需要在每个命名空间中单独运行实例，并且由于默认套接字相同，还需要为每个实例创建独特的套接字。这不仅增加了系统的开销，还使得管理变得更加复杂。相比之下，VRF 在隔离三层网络结构的同时，允许全局配置的共享和非三层感知服务的统一运行，大大提高了资源的利用效率。

Policy Routing	VRF	Net Namespace
隔离路由表	隔离三层网络	整个协议栈从二层到 socket 隔离

VRF 配置

在 Linux 系统中配置 VRF，主要借助iproute2包来完成一系列操作。

创建 VRF，并关联到 table 1

test1@test1:~$ ip link add vrf-1 type vrf table 1
test1@test1:~$ ip link set vrf-1 up

添加接口到 VRF，可以看到 wg0 的 master 是 vrf-1，所有 wg0 的流量会使用关联的 vrf-1 路由表进行路由

test1@test1:~$ ip link set wg0 master vrf-1
test1@test1:~$ ip -d link show wg0 
9: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue master vrf-1 state UNKNOWN mode DEFAULT group default qlen 1000
    link/none  promiscuity 0 minmtu 0 maxmtu 2147483552 
    wireguard 
    vrf_slave table 1 addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

添加和查看 VRF 静态路由

root@test1:~# ip route add default via 10.1.0.10 vrf vrf-1
root@test1:~# ip route show table 1 
default via 10.1.0.10 dev wg0 
local 10.1.0.10 dev wg0 proto kernel scope host src 10.1.0.10 
root@test1:~# ip route show vrf vrf-1 
default via 10.1.0.10 dev wg0

VRF 之间路由

有两种方法可以执行跨 VRF 路由。第一种方法涉及一个 VRF 的表中配置的路由，指向绑定到不同 VRF 的设备。

eBPF 指令集规范

Fri, 05 Jan 2024 18:06:28 +0800

1 BPF Instruction Set Specification, v1.0 — The Linux Kernel documentation

寄存器和调用约定

eBPF有10个通用寄存器和一个只读的帧指针寄存器，所有的寄存器都是64bits位长。

eBPF的调用约定如下：

R0: 函数调用的返回值和eBPF程序的退出值
R1 - R5: 函数调用的参数
R6 - R9: callee saved registers，由函数调用负责保存到栈上
R10: 只读的帧指针，用于访问栈 R0 - R5是临时寄存器，eBPF程序在函数调用时如需使用需要将它们保存/填充。

指令编码

eBPF使用64bit指令，编码如下：

32位（最高有效位）	16位	4位	4位	8位（最低有效位）
immediate	offset	source register	dest register	opcode

imm: 有符号整型立即数
offset: 有符号整型数，用于指针算术
src_reg: 除开特殊指令的编码外（如64位立即数指令）指的是源寄存器(R0 - R10)
dst_reg: 目标寄存器(R0 - R10)
opcode: 操作码

绝大多数指令不会使用所有的字段。没有使用的字段应当被置0。多字节的字段（如imm和offset）在大端BPF中以大端字节序存储，小端BPF中以小端字节序存储。

opcode                  offset imm          assembly
       src_reg dst_reg
07     0       1        00 00  44 33 22 11  r1 += 0x11223344 // little
       dst_reg src_reg
07     1       0        00 00  11 22 33 44  r1 += 0x11223344 // big

除了这些基本指令编码外，eBPF还有一种宽指令编码，在基本指令之后使用第2个64位立即数做扩展。第2个立即数包括一个伪指令，和基本指令的格式一样，不过所有的字段（除了imm）都置为0。它的imm作为整个宽指令中的imm64值的高32位：

eBPF 全局变量的实现

Tue, 02 Jan 2024 19:46:28 +0800

Linux内核在v5.2支持了eBPF全局变量（见v5.2）。

全局变量会被Clang编译器放入.bss, .data, .rodata sections。那么支持全局变量即如何把这些sections中的数据加载进内核，并且在relocation时，给访问这些变量的指令正确的地址。

早期 workaround

关于 eBPF 静态变量支持的讨论在Linux Plumbers Conference 2018 由Cilium提出。早期的 workaround 如下：

#include <linux/bpf.h>

typedef unsigned int __u32;
typedef long long unsigned int __64;

#ifndef __section
# define __section(NAME)				\
	__attribute__((section(NAME), used))
#endif
#ifndef __fetch
# define __fetch(x) (__u32)(__u64)(&(x))
#endif

__u32 foo = 42; 			// .data section
// __u32 foo;   			// .bss section
// const __u32 foo = 42; 	// .rodata section

int __main(struct __sk_buff *skb)
{
    skb->mark = __fetch(foo);
    return 0;
}

char __license[] __section("license") = "";

编译后，foo变量存储在.data section内。

# llvm-readelf -S test.o
There are 8 section headers, starting at offset 0x148:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .strtab           STRTAB          0000000000000000 0000fa 00004b 00      0   0  1
  [ 2] .text             PROGBITS        0000000000000000 000040 000028 00  AX  0   0  8
  [ 3] .rel.text         REL             0000000000000000 0000e8 000010 10      7   2  8
  [ 4] .data             PROGBITS        0000000000000000 000068 000004 00  WA  0   0  4
  [ 5] license           PROGBITS        0000000000000000 00006c 000001 00  WA  0   0  1
  [ 6] .llvm_addrsig     LLVM_ADDRSIG    0000000000000000 0000f8 000002 00   E  7   0  1
  [ 7] .symtab           SYMTAB          0000000000000000 000070 000078 18      1   2  8
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  p (processor specific)

.rel.text section中也存在foo变量的relocation信息：

Linux 收包和发包流程

Thu, 13 Oct 2022 14:30:28 +0800

流程图

From 《Understanding Linux Network Internals》

收包流程

TL; DR

收包NET_RX_SOFTRQ的软中断处理函数是net_rx_action
net_rx_action中会调用网卡驱动注册的poll回调函数处理
poll回调函数将数据帧从网卡ring buffer中取出，构造skb：
- 运行xdpdrv上的bpf program，得到action result
- 如果是XDP_PASS，构造skb，并初始化skb中一些metadata字段
调用内核的GRO和RPS处理流程
进入__netif_receive_skb_core，处理skb：
- 运行xdpgeneric上的bpf program，得到action result
- 如果是XDP_PASS，遍历ptype_all和dev->ptype_all，进行抓包处理
- tc ingress 处理sch_handle_ingress
- 查找ptype_base和dev->ptype_specific，交由对应的三层协议栈回调函数处理

NAPI

**NAPI的思想是从完全的中断收包模型，改用中断和polling混合。**如果内核在处理旧的数据帧时，收到了新的数据帧，网卡设备没有必要再触发一个中断。内核继续处理设备input queue里的数据（该设备的interrupt禁止了），在队列为空时重新使能中断。

从内核的角度，NAPI有如下的优势：

降低CPU的负载（更少的中断）
更多的设备处理公平性

以ixgbe网卡为例，描述下NAPI处理流程。

注册

ixgbe驱动在初始化中断向量时会调用netif_napi_add初始化NAPI，==将ixgbe_poll函数注册到napi结构体，并将napi加入到设备的napi_list内==：

/**
 * ixgbe_alloc_q_vector - Allocate memory for a single interrupt vector
 * @adapter: board private structure to initialize
 * @v_count: q_vectors allocated on adapter, used for ring interleaving
 * @v_idx: index of vector in adapter struct
 * @txr_count: total number of Tx rings to allocate
 * @txr_idx: index of first Tx ring to allocate
 * @xdp_count: total number of XDP rings to allocate
 * @xdp_idx: index of first XDP ring to allocate
 * @rxr_count: total number of Rx rings to allocate
 * @rxr_idx: index of first Rx ring to allocate
 *
 * We allocate one q_vector.  If allocation fails we return -ENOMEM.
 **/
static int ixgbe_alloc_q_vector(struct ixgbe_adapter *adapter,
                int v_count, int v_idx,
                int txr_count, int txr_idx,
                int xdp_count, int xdp_idx,
                int rxr_count, int rxr_idx)
{
	/* ... */

    /* initialize NAPI */
    netif_napi_add(adapter->netdev, &q_vector->napi,
               ixgbe_poll, 64);
}

中断处理函数

ixgbe驱动收到中断后，会调用ixgbe_msix_clean_rings

make命令和编译

Tue, 26 Jul 2022 14:30:28 +0800

Makefile

标准格式

target：dependencies1 dependencies2 ...
   recipe

.PHONY: clean
clean:
   -rm ...

注意事项

运行make时如果没有指定target，那么make会构建Makefile中的第一个target
通常情况下，目标名即生成的文件名。如果一条规则的目标文件存在并且该文件比它所有的依赖都要新，那么make会跳过recipe；如果目标文件不存在，那么目标文件的 timestamp 为开始的时间；否则timestamp为相应文件的修改时间。
每次运行 make clean，”clean“中的recipe都会被执行，因为clean文件永远都不会被创建。（可以使用 .PHONY 创建伪目标使Makefile可读性更高）
recipes必须用tab缩进
可以通过并行的方式运行recipes：make -j 4（指定并行的任务数）
如果没有指定规则，Make会自动化创建规则。例如，本地有一个C文件”program.c“，当运行 make program时，Make会自动编译生成 program

变量

$@ 目标文件
$^ 所有的依赖文件
$< 第一个依赖

头文件

环境变量

C_INCLUDE_PATH C语言头文件路径
CPLUS_INCLUDE_PATH C++ 头文件路径

搜索路径

#include<>

先搜索 -I 指定的目录
然后搜索gcc的环境变量 CPLUS_INCLUDE_PATH
最后搜索gcc的内定目录
1. /usr/include
2. /usr/local/include
3. /usr/lib/gcc/x86_64-redhat-linux/4.1.1/include

#include ""

搜索当前目录，#include<>方式不会搜索当前目录

动态库

环境变量

LD_LIBRARY_PATH 动态链接库搜索路径
PKG_CONFIG_PATH .pc文件（package config）文件搜索路径

搜索路径

首先在环境变量 LD_LIBRARY_PATH 所记录的路径中查找
在程序链接时指定的 rpath 中查找，可以 readelf binfile | grep RPATH
然后从缓存文件/etc/ld.so.cache中查找。这个缓存文件由/sbin/ldconfig命令读取配置文件/etc/ld.so.conf 之后生成（也可以在 ld.so.conf.d 目录下增加 .conf 文件，里面写入库路径，在 ld.so.conf 中 include ld.so.conf.d/.conf ）
如果上述步骤都找不到，则到默认的系统路径中查找，先是/usr/lib然后是/lib

https://www.cnblogs.com/masterpanda/p/5700446.html

编译参数

-shared

指定生成动态连接库

ELF 文件格式浅析

Fri, 27 May 2022 09:30:28 +0800

本文是作为 Rust 的练手项目 rself(https://github.com/chengzhycn/rself) 的背景知识记录。rself 使用 Rust 重新造了一个 readelf 的轮子。

ELF全称为Executable and Linkable Format，是Linux上可执行文件的通用文件格式。主要有三种类型的ELF文件：

Relocatable file: 存储用于和其它对象文件链接的代码和数据，创建一个可执行文件或者共享对象文件
Executable file: 存储的是用于执行的程序。它指定了exec如何创建一个程序的进程镜像
Shared object file: 存储了在两种语义下用于链接的代码和数据。第一种是让链接器将共享对象文件和其它的可重定位文件/共享对象文件一起创建一个新的对象文件；第二种是动态链接器将它和可执行文件以及其它的共享对象一起创建一个进程镜像。

ELF构成

ELF主要由如下几个部分组成：

ELF Header: 位于文件的起始，描述了整个文件的组织结构
Sections/Segments: 存储了指令、数据、符号表、可重定位信息等。sections 是这段数据在链接时的表现；segments 是数据在执行时的表现。
Program Header Table: 用于告诉系统如何创建一个进程镜像。对于可执行程序，Program Header Table是必须的，但是对于可重定位文件就不需要了。
Section Header Table: 存储描述文件中sections的信息。每个section都在这个表中有一个条目，存储了如section name, section size等信息。用于链接的文件必须得有Section Header Table，其它的对象文件可有可无。

上面的图中虽然描述文件各个部分的位置，但实际上只有ELF Header的位置是固定的，其它的部分在文件中的位置都在ELF Header中指定。

ELF Header

#define EI_NIDENT 16

typedef struct {
        unsigned char   e_ident[EI_NIDENT];
        Elf32_Half      e_type;
        Elf32_Half      e_machine;
        Elf32_Word      e_version;
        Elf32_Addr      e_entry;
        Elf32_Off       e_phoff;
        Elf32_Off       e_shoff;
        Elf32_Word      e_flags;
        Elf32_Half      e_ehsize;
        Elf32_Half      e_phentsize;
        Elf32_Half      e_phnum;
        Elf32_Half      e_shentsize;
        Elf32_Half      e_shnum;
        Elf32_Half      e_shstrndx;
} Elf32_Ehdr;

typedef struct {
        unsigned char   e_ident[EI_NIDENT];
        Elf64_Half      e_type;
        Elf64_Half      e_machine;
        Elf64_Word      e_version;
        Elf64_Addr      e_entry;
        Elf64_Off       e_phoff;
        Elf64_Off       e_shoff;
        Elf64_Word      e_flags;
        Elf64_Half      e_ehsize;
        Elf64_Half      e_phentsize;
        Elf64_Half      e_phnum;
        Elf64_Half      e_shentsize;
        Elf64_Half      e_shnum;
        Elf64_Half      e_shstrndx;
} Elf64_Ehdr;

ELF header通常由一个Elfxx_Ehdr结构体表示。它存储了当前二进制文件的一些元数据：

Linux 进程调度

Tue, 11 Jan 2022 14:30:28 +0800

总体来说，调度主要解决两类问题：

什么时候调度
调度的目标是谁而一个优秀的调度系统，可以从如下几个指标判断：
fast process response time
good throughput for background jobs
avoidance of process starvation
reconciliation of the needs of low- and high- priority processes

Linux调度基于分时（Time-Sharing）：多个进程共享同一个CPU，CPU运行时切分成多个时间片。分时技术依赖于timer interrupt，对进程来说是透明的。

Linux进程是可抢占的。当进程切换到TASK_RUNNING状态，内核检查其动态优先级是否比当前运行的进程的优先级高。如果更高，当前执行的进程中断掉，调度器切入，选择另外一个进程运行（通常是刚刚切换成runnable的进程）。当进程的时间片消耗完毕时，进程也是可被抢占的。当前进程struct thread_info中的TIF_NEED_RESCHED被设置，timer interrupt handler终止后，scheduler切入。

一个被抢占的进程并不是被暂停，它还维持在TASK_RUNNING状态，只不过不再使用CPU。

调度算法

Linux 2.6版本之前的调度算法很简单，进程切换时，内核扫描runnable进程列表，计算它们的优先级，选择“最优”的进程运行。这种算法的问题是切换时的时间开销会随着进程数目的增多呈线性增长。

调度策略：

SCHED_FIFO
SCHED_RR
SCHED_NORMAL

O(1) Scheduler

基于Linux-2.6.12版本。

优先级

Linux 2.6.12 内核里，优先级表示分为用户态和内核态。用户态优先级就是我们常用的nice值。取值范围[-20, 19]。内核态优先级被称作静态优先级（static priority），取值范围是[0, 139]。其中，[0, 99]是Real-Time Process，[100, 139]对应用户态nice值。

在静态优先级外，真正发挥作用的是动态优先级（dynamic priority）。动态优先级实际上是静态优先级加上了一个运行时补偿（bonus）： $$ dynamic_priority = max(100, min((static_priority - 5 + bonus), 139)), bonus \in [0, 10] $$

Linux 进程

Tue, 30 Nov 2021 08:30:28 +0800

进程和轻量级进程

在Linux内核中，进程/线程对应的数据结构是task_struct，定义在include/linux/sched.h中。

线程在Linux中的实现是 Naive POSIX Thread Library 。在内核眼中，Linux的线程实际上也是一个进程（task_struct），区别是线程的“进程”共享了地址空间、文件描述符等，称作==轻量级进程==。因此，Linux的线程也是独立的调度单元，是可以分别在不同的CPU上同时运行的。原生的Linux 线程（2.6版本内核之前）因为只实现在了用户态，所以，即使是一个多线程程序，对于内核来说只能看到一个进程，这些线程就只能在一个CPU上运行，对于多核多线程来说是很致命的。

从实现的角度，Linux的线程（LWP）是通过pthread库创建/使用的。而进程和线程的创建都调用了clone()系统调用（kernel/fork.c ）。区别是两者使用了不同的flags。

进程管理

进程状态

TASK_RUNNING: The process is either executing on a CPU or waiting to be executed
TASK_INTERRUPTIBLE: The process is suspended (sleeping) until some condition becomes true.
TASK_UNINTERRUPTIBLE: Like TASK_INTERRUPTIBLE, except that delivering a signal to the sleeping process leaves its state unchanged.

PID

PID用来区分不同的进程结构体。Linux中最大PID数目可以在/proc/sys/kernel/pid_max中查看。

每个进程/轻量级进程都分配有一个唯一的PID。但是对于同一进程中的线程来说，我们拿到的是进程ID确是相同的，这是怎么实现的呢？

Linux为了兼容POSIX标准，利用了线程组（thread group）这一概念。所有的线程都会把线程组里面第一个线程的PID存在tgid字段内。==getpid()系统调用返回的实际上是tgid的值。==

/**
 * sys_getpid - return the thread group id of the current process
 *
 * Note, despite the name, this returns the tgid not the pid.  The tgid and
 * the pid are identical unless CLONE_THREAD was specified on clone() in
 * which case the tgid is the same in all threads of the same group.
 *
 * This is SMP safe as current->tgid does not change.
 */
SYSCALL_DEFINE0(getpid)
{
    return task_tgid_vnr(current);
}

bitmap管理PID

IDR管理PID

PID: replace pid bitmap implementation with IDR API commit, commit

进程切换

==TLDR：进程在调用schedule()方法时，将当前进程运行的寄存器信息保存在task_struct->thread_info内，同时从进程B中的task_struct->thread_info中加载B运行时的寄存器信息。==

Go channel 实现

Sun, 12 Sep 2021 09:30:28 +0800

Go的Channel在runtime里面是一个hchan的结构体，每次我们make一个新的channel时，runtime从heap内分配一个hchan结构体管理channel。

type hchan struct {
    qcount   uint           // total data in the queue
    dataqsiz uint           // size of the circular queue
    buf      unsafe.Pointer // points to an array of dataqsiz elements
    elemsize uint16
    closed   uint32
    elemtype *_type // element type
    sendx    uint   // send index
    recvx    uint   // receive index
    recvq    waitq  // list of recv waiters
    sendq    waitq  // list of send waiters

    // lock protects all fields in hchan, as well as several
    // fields in sudogs blocked on this channel.
    //
    // Do not change another G's status while holding this lock
    // (in particular, do not ready a G), as this can deadlock
    // with stack shrinking.
    lock mutex
}

qcount：当前channel queue内的element数目，当qcount等于dataqsiz时，表示channel buffer已经满了，send channel会被阻塞；
dataqsiz：channel的buffer大小，也就是我们在make时设定的值。dataqsiz在channel创建后不会再变动，因此channel的buffer是不会动态扩容的；
buf：buffered channel缓存elements的内存地址。是一个数组实现的环形队列；
elemsize：element类型大小；
closed：channel是否已经被关闭，防止关闭已经关闭的channel；
elemtype：channel element 类型；
sendx：buffer中下一个生产的element的index；
recvx：buffer中下一个消费的element的index；
recvq：阻塞的接收channel，是一个sudog的链表
sendq：阻塞的发送channel，是一个sudog的链表

当buffer没有满时，send channel发送elements时直接把elements放在buf内，增加sendx和qcount；当buffer满时，send channel被阻塞，并加入到sendq链表内，等待被唤醒；

Rust: Concurrency

Sun, 27 Jun 2021 09:30:28 +0800

为什么Rust不做green threading

Send 和 Sync

Rust中几乎所有的并发特性都是标准库或者第三方库提供的，真正由Rust语言本身提供的很少。而std::marker中的traits Send和Sync算是其中一个。

**实现Send的类型值的所有权可以在线程间传递。**Rust中绝大多数类型都实现了Send，但也有些例外，如Rc<T>：因为如果将Rc<T>的拷贝值的所有权在多个线程中传递，Rust无法保证Rc<T>引用值的正确性。

实现Sync的类型表示该类型值可以在多个线程中被引用。也就是说，如果&T实现了Send，那么类型T就是Sync。

Send和Sync markers其实就是将其他语言中的一些潜规则显式地标明出来，让编译器提前检查出代码中的隐患。

线程原语

use std::thread;

fn main() {
    let v = vec![1, 2, 3];

    let handle = thread::spawn(move || {
        println!("Here's a vector: {:?}", v);
    });

    handle.join().unwrap();
}

thread::spawn新建一个线程，执行传递的闭包函数，返回一个JoinHandler，可以在主线程中调用join等待子线程结束。move用于强制闭包获取它使用的变量的所有权。

我们可以看看thread::spawn的实现：

#[stable(feature = "rust1", since = "1.0.0")]
pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T,
    F: Send + 'static,
    T: Send + 'static,
{
    Builder::new().spawn(f).expect("failed to spawn thread")
}

spawn的入参和返回值都实现Send，同时其生命周期为'static。这是因为在多线程中，每个线程的执行周期不是同步的。父线程或者子线程的结束都会导致入参或者返回值的生命周期不满足Rust的约束条件。

Rust：Generic and Traits

Fri, 25 Jun 2021 14:30:28 +0800

泛型

Rust 泛型会在编译时根据参数将泛型单态化（Monomorphization ），因此，Rust 泛型在运行时是没有任何损耗的。

泛型在函数定义

fn largest<T: std::cmp::PartialOrd + Copy>(list: &[T]) -> T {
    let mut largest = list[0];

    for &item in list {
        if item > largest {
            largest = item;
        }
    }

    largest
}

fn main() {
    let number_list = vec![34, 50, 43, 15];
    println!("the largest number is {}", largest(&number_list));

    let char_list = vec!['y', 'm', 'c', 'd'];
    println!("the largest char is {}", largest(&char_list));
}

泛型在结构体定义

struct Point<T> {
    x: T,
    y: T,
}

fn main() {
    let p = Point{x: 5, y: 3};
    println!("x is {}, y is {}", p.x, p.y);

    let p = Point{x: 5.0, y: 3.0};
    println!("x is {}, y is {}", p.x, p.y)
}

需要注意，这里表示结构体内x和y是同一种类型，如果需要x和y类型不同，需要定义两个泛型参数。

Rust：Ownership

Wed, 23 Jun 2021 22:24:24 +0800

所有权（Ownership）是Rust中最独特的特性之一。正是因为所有权，Rust才能够在不需要GC的情况下保证内存安全。

我们常用的语言中，内存管理一般分为两种：

自管理，谁分配的谁负责回收，如果没有回收，就会导致内存泄漏。如C、C++。
由统一的垃圾回收器管理，GC负责追踪和管理已分配内存，如果内存不再被使用，则由GC进行回收。

Rust选择了第三种，内存会在拥有它的变量离开作用域时回收。因此，理解Rust的内存管理，就需要理解Rust中的所有权、借用规则、生命周期等概念。Rust会在编译过程中校验变量是否符合借用规则，从而保证运行时的内存安全，而且没有GC的额外开销。

在C++中，这种模式也被称作Resource Acquisition Is Initialization (RAII)。

所有权基本规则

所有权有三条基本规则：

Rust中每个值都有一个对应的变量称之为所有者（owner）；
同一时刻，一个值只能存在一个所有者；
当所有者离开作用域时，其拥有的值会被丢弃。

copy和move

因为同一时刻，一个值只能存在一个所有者，对于所有权的转让，Rust根据对象类型分为两种。

一种是Copy。即将值做拷贝，拷贝后，原变量拥有原值的所有权，新变量拥有新值的所有权，没有所有权的转移，两者可以同时使用。

let x = 5;
let y = x;
println!("x is {}, y is {}", x, y); // valid

支持Copy操作常见的类型通常是只存储在栈上的数据类型，如：

所有的integer类型，如u32；
bool值；
char值；
所有的float类型，如f64；
元组，如果其包含的类型也都是支持Copy的。

这些类型都实现了Copy特型。如果一种类型实现了Copy特型，在分配新变量后，原变量仍是可用的。

另外一种是Move。对于类似String这种在栈上存储了元数据，实际数据存储在堆上的数据类型来说，将原变量赋给新变量实际上是将堆上数据的所有权转移给新变量，原变量在赋值后不再使用。

let s1 = String::from("hello!!!");
let s2 = s1;
println!("s2 is {}, s1 is {}", s2, s1); // invalid, s1 is no longer valid any more.