even629https://even629.com/en/icon.pngblog2026-07-11T16:00:00.000Zhttps://even629.com/en/even629HexoTag Plugin Plus External Tags Overviewhttps://even629.com/en/posts/50013/2026-07-11T12:00:00.000Z2026-07-11T16:00:00.000Z Timeline
Timeline
2026-07-11
init
This article introduces the rendering support test of the current theme for standard Markdown and extended syntax, and provides a detailed overview of the Tag Plugin Plus external tags ported from the Butterfly theme to the Cactus theme, including the syntax and rendering effects of components such as link cards, inline text tags, prompts, collapsible boxes, timelines, and tab pages.
Markdown Basic Syntax
The following tests the current theme’s rendering support for standard Markdown and extended syntax.
This is a paragraph containingunderline、emphasisandwavy linemixed text.
Syntax:{% Tag name Text content %} — No closing tag
Colored paragraph (p) and inline (span)
Color test
Red paragraph text
Blue paragraph text
Green paragraph
Yellow paragraph
cyan paragraph
purple paragraph
gray paragraph
inline span
This is a piece of text, which containsred textandblue text。
alignment
centered paragraph text
Right-aligned paragraph text
Font size
Large font paragraph
Extra large font paragraph
Syntax:{% p Color, Text %} / {% span Color, Text %} — Colors support Chinese and English (red/red, blue/blue, etc.)
Tip box (tip)
Basic style
Default style tip box
Info style tip
Success style tip (success tip)
tip with warning style (warning prompt)
tip with danger style (danger prompt)
extended styles
bolt style (lightning icon)
ban style (prohibition icon)
home style (home icon)
sync style (sync icon)
cogs style (gear icon)
key style (key icon)
bell style (bell icon)
Syntax:{% tip Style name %} Content {% endtip %} — Styles: info / success / warning / danger / bolt / ban / home / sync / cogs / key / bell
Folding container (folding)
Default style
Click to expand for details
Content in the collapsible box, supports Markdown syntax.
List item
Inline code
1
console.log("折叠框内的代码");
Color variant
Blue collapsible
Collapsible box with blue border
Red collapsible
1
printf("红色折叠内的代码块\n");
Green collapsible
Green collapsible box content
Purple collapsible
Purple collapsible box content
Cyan collapsible
Cyan collapsible box content
Yellow collapsible
Yellow collapsible box content
Orange collapsible
Orange collapsible box content
Collapsible box expanded by default
Green collapsible box expanded by default
This collapsible box is expanded by default (add open key word).
Table embedded in collapsible box
Table inside collapsible box
Name
Value
Attribute A
100
Attribute B
200
Collapsible box nesting
Outer collapsible
Outer content
Inner collapsible
Inner content
Syntax:{% folding [Color] [open], Title %} Content {% endfolding %} — Color (optional): blue / red / green / purple / cyan / yellow / orange; add open Keyword makes the collapsible box expanded by default
Timeline (timeline)
Blue timeline
My timeline
2024年
Started a blog and built a Hexo site.
2025年
Migrate to Cactus theme to optimize reading experience.
2026年
Improve plugin tags and add English translations.
Green timeline
Project progress
Q1
Requirements analysis and design
Q2
Core feature development
Q3
Testing and deployment launch
Other color variants
Red timeline
节点一
Red timeline node content
节点二
Contains Bold and code node
Orange timeline
橙色节点
Orange timeline node content
Purple timeline
紫色节点
Purple timeline node content
Syntax:{% timeline Title, Color %} Content {% endtimeline %} — Color: blue / green / red / orange / purple
Tabs
Basic tabs
C is a general-purpose procedural programming language.
1
printf("hello\n");
Rust is a systems programming language focused on safety.
1
println!("hello");
Python is a concise and elegant interpreted language.
1
print("hello")
Specify the default active tab
Content of the first tab
Content of the second tab
Content of the third tab, automatically displayed when the page loads.
Tabs with icons
Code-related content
Design-related content
Syntax:{% tabs Title, Default active index %} Content {% endtabs %} — With icons:<!-- tab @fa-icon-class -->
Multi-level tabs (subtabs)
This is the content of the first-level tab A.
Content of sub-tab 1
Content of sub-tab 2
Content of the first-level tab B.
Syntax: In tab inner nesting subtabs / subsubtabs(same syntax as tabs）
Annotation box (note)
Four basic styles
Flat style note (default), suitable for general reminders.
Modern style note, clean solid background.
Simple style note, with a colored border on the left.
Disabled style note, gray tones.
Note with title
Precautions
Please read the documentation carefully before use.
Note with icon
Tip
Note with light bulb icon as a reminder.
Warning
Note with warning icon.
Note with embedded Markdown
Supports bold、italic、code and other inline formats.
List item
Can also have code blocks
1
const msg = "hello";
Title + Icon + Style combination
modern Modern style with title
Modern note with title, icon, and style all present.
simple Simple style with title
Simple style + title + light bulb icon.
disabled Disabled with title
Disabled style + title, no icon.
Syntax:{% note Title(Optional), Icon(Optional) %} Content {% endnote %} — Style controlled via CSS class
Progress bar (progress)
Basic colors
90% Completed
60% In Progress
30% Blocked
Extended colors
info Progress
primary Progress
blue Progress
gray Progress
Boundary values
100% All Completed
0% Not Started
Syntax:{% progress Width percentage, Color, Label text %} — Color: success / warning / danger / info / primary / blue / gray
Checkbox
Default state
Apple
Banana
Strawberry
Selected state
Watermelon
Grape
Color variants
checkbox
checkbox
checkbox
checkbox
checkbox
style variant
sign style
sign style
cross sign style
radio button
option one
option two
button
color and style overlay
sign
sign
cross sign
button
sign
Syntax:{% checkbox Text, checked(Optional) %} — Color/style placed before text:red / green / blue / yellow / cyan / plus / minus / times / radio
Bubble note (bubble)
Default color
Move the mouse tothis word This is the annotation textto view the annotation.
Custom color
another word another annotation
Consecutive bubbles
A sentence can havemultiple first commentbubble second commentarranged in order.
Syntax:{% bubble text, comment, color(optional) %} — no closing tag, hover to show comment
reference tag (referto + referfrom)
single reference
reference mark in text1HexoOfficial documentation, click the number to jump to the references at the end of the document.
The second footnote can containformattingandcode。 ↩︎
]]>This article introduces the rendering support test of the current theme for standard Markdown and extended syntax, and provides a detailed overview of the Tag Plugin Plus external tags ported from the Butterfly theme to the Cactus theme, including the syntax and rendering effects of components such as link cards, inline text tags, prompts, collapsible boxes, timelines, and tab pages.Remoteproc resource tablehttps://even629.com/en/posts/202607041/2026-07-04T09:42:13.000Z2026-07-04T09:42:13.000Z Timeline
Timeline
2026-07-04
init
This article introduces the structure and function of the resource table in the remote processor firmware image, detailing how the main processor, after loading the firmware, decodes the resource table to allocate system resources such as physical memory, configure Virtio devices, and create RPMsg channels for inter-core communication. Additionally, using the STM32MP15C reference code, it summarizes the specific definitions of resource entries under the Remoteproc framework and the implementation of dynamic resource management based on OpenAMP.
The firmware image of a remote processor generally includes:
Resource table (resource_table)
User application
RTOS or bare metal (BM) related code
OpenAMP library.
After the main processor loads the remote processor’s firmware into the remote processor’s core, it decodes the firmware image to obtain associated resources and reserves memory for the firmware code and data segments. Once the remote processor is started, the main processor creates an RPMsg channel, which is used for remote communication.
remoteproc_image.drawio
The resources of the remote processor include:
System resources required by the remote processor before power-up, such as contiguous physical memory allocated to the remote processor and peripherals assigned to it (these devices can be reserved or unused), are configured in thestm32mp157-m4-srm.dtsiresource manager of the device tree file (i.e., them4_system_resourcesnode).
In addition to system resources, each remote processor has a resource table (resource_table), and the resource table may also contain resource entries that publish the functions supported by the remote processor or existing configurations, such as the vring address and vring size in Virtio devices.
Only after all resource requirements are met (M-core side configuration requirements, the resource table will require Linux to allocate corresponding resources, etc.), Remotecore will start the device.
Resource Table
Under the kernel source codeinclude/linux/remoteproc.hfile, find the following structure resource_table, which is the firmware resource table header:
/** * struct resource_table - firmware resource table header * @ver: version number * @num: number of resource entries * @reserved: reserved (must be zero) * @offset: array of offsets pointing at the various resource entries * * A resource table is essentially a list of system resources required * by the remote processor. It may also include configuration entries. * If needed, the remote processor firmware should contain this table * as a dedicated ".resource_table" ELF section. * * Some resources entries are mere announcements, where the host is informed * of specific remoteproc configuration. Other entries require the host to * do something (e.g. allocate a system resource). Sometimes a negotiation * is expected, where the firmware requests a resource, and once allocated, * the host should provide back its details (e.g. address of an allocated * memory region). * * The header of the resource table, as expressed by this structure, * contains a version number (should we need to change this format in the * future), the number of available resource entries, and their offsets * in the table. * * Immediately following this header are the resource entries themselves, * each of which begins with a resource entry header (as described below). */ structresource_table { u32 ver; u32 num; u32 reserved[2]; u32 offset[]; } __packed;
Following this firmware resource table header are the resource entries themselves. Each entry starts with astruct fw_rsc_hdrheader, and the content of the entry itself follows this header, parsed according to the resource type. Below is the beginning of the resource entry header:
struct fw_rsc_hdr
1 2 3 4 5 6 7 8 9 10 11 12 13
/** * struct fw_rsc_hdr - firmware resource entry header * @type: resource type * @data: resource data * * Every resource entry begins with a 'struct fw_rsc_hdr' header providing * its @type. The content of the entry itself will immediately follow * this header, and it should be parsed according to the resource type. */ structfw_rsc_hdr { u32 type; u8 data[]; } __packed;
/** * enum fw_resource_type - types of resource entries * * @RSC_CARVEOUT: request for allocation of a physically contiguous * memory region. * @RSC_DEVMEM: request to iommu_map a memory-based peripheral. * @RSC_TRACE: announces the availability of a trace buffer into which * the remote processor will be writing logs. * @RSC_VDEV: declare support for a virtio device, and serve as its * virtio header. * @RSC_LAST: just keep this one at the end of standard resources * @RSC_VENDOR_START:start of the vendor specific resource types range * @RSC_VENDOR_END:end of the vendor specific resource types range * * For more details regarding a specific resource type, please see its * dedicated structure below. * * Please note that these values are used as indices to the rproc_handle_rsc * lookup table, so please keep them sane. Moreover, @RSC_LAST is used to * check the validity of an index before the lookup table is accessed, so * please update it as needed. */ enumfw_resource_type { RSC_CARVEOUT= 0, RSC_DEVMEM= 1, RSC_TRACE= 2, RSC_VDEV= 3, RSC_LAST= 4, RSC_VENDOR_START= 128, RSC_VENDOR_END= 512, };
The above values are used asrproc_handle_rsc()indices for the lookup table of the function (in theremoteproc_internal.hfile).
When registering a new remote processor, the Remoteproc framework will look up its resource table and register the Virtio devices it supports. The firmware should provide Remoteproc information about the Virtio devices it supports and their configurations,RSC_VDEVand the resource entry should specify the Virtio device ID (such asvirtio_ids.h), Virtio functions, Virtio configuration space, vrings information, etc. We can obtain this by checking the Linux file system/sys/kernel/debug/remoteproc/remoteproc0/resource_tablefile to get the RSC_VDEV information. (That is, through therproc_handle_rsc()function to first look up the relevant attributes, and then go toRSC_VDEVto find the specific configuration of that attribute.)
/** * struct fw_rsc_carveout - physically contiguous memory request * @da: device address * @pa: physical address * @len: length (in bytes) * @flags: iommu protection flags * @reserved: reserved (must be zero) * @name: human-readable name of the requested memory region * * This resource entry requests the host to allocate a physically contiguous * memory region. * * These request entries shonuld precede other firmware resource entries, * as other entries might request placing other data objects inside * these memory regions (e.g. data/code segments, trace resource entries, ...). * * Allocating memory this way helps utilizing the reserved physical memory * (e.g. CMA) more efficiently, and also minimizes the number of TLB entries * needed to map it (in case @rproc is using an IOMMU). Reducing the TLB * pressure is important; it may have a substantial impact on performance. * * If the firmware is compiled with static addresses, then @da should specify * the expected device address of this memory region. If @da is set to * FW_RSC_ADDR_ANY, then the host will dynamically allocate it, and then * overwrite @da with the dynamically allocated address. * * We will always use @da to negotiate the device addresses, even if it * isn't using an iommu. In that case, though, it will obviously contain * physical addresses. * * Some remote processors needs to know the allocated physical address * even if they do use an iommu. This is needed, e.g., if they control * hardware accelerators which access the physical memory directly (this * is the case with OMAP4 for instance). In that case, the host will * overwrite @pa with the dynamically allocated physical address. * Generally we don't want to expose physical addresses if we don't have to * (remote processors are generally _not_ trusted), so we might want to * change this to happen _only_ when explicitly required by the hardware. * * @flags is used to provide IOMMU protection flags, and @name should * (optionally) contain a human readable name of this carveout region * (mainly for debugging purposes). */ structfw_rsc_carveout { u32 da; u32 pa; u32 len; u32 flags; u32 reserved; u8 name[32]; } __packed;
/** * struct fw_rsc_devmem - iommu mapping request * @da: device address * @pa: physical address * @len: length (in bytes) * @flags: iommu protection flags * @reserved: reserved (must be zero) * @name: human-readable name of the requested region to be mapped * * This resource entry requests the host to iommu map a physically contiguous * memory region. This is needed in case the remote processor requires * access to certain memory-based peripherals; _never_ use it to access * regular memory. * * This is obviously only needed if the remote processor is accessing memory * via an iommu. * * @da should specify the required device address, @pa should specify * the physical address we want to map, @len should specify the size of * the mapping and @flags is the IOMMU protection flags. As always, @name may * (optionally) contain a human readable name of this mapping (mainly for * debugging purposes). * * Note: at this point we just "trust" those devmem entries to contain valid * physical addresses, but this isn't safe and will be changed: eventually we * want remoteproc implementations to provide us ranges of physical addresses * the firmware is allowed to request, and not allow firmwares to request * access to physical addresses that are outside those ranges. */ structfw_rsc_devmem { u32 da; u32 pa; u32 len; u32 flags; u32 reserved; u8 name[32]; } __packed;
/** * struct fw_rsc_trace - trace buffer declaration * @da: device address * @len: length (in bytes) * @reserved: reserved (must be zero) * @name: human-readable name of the trace buffer * * This resource entry provides the host information about a trace buffer * into which the remote processor will write log messages. * * @da specifies the device address of the buffer, @len specifies * its size, and @name may contain a human readable name of the trace buffer. * * After booting the remote processor, the trace buffers are exposed to the * user via debugfs entries (called trace0, trace1, etc..). */ structfw_rsc_trace { u32 da; u32 len; u32 reserved; u8 name[32]; } __packed;
/** * struct fw_rsc_vdev_vring - vring descriptor entry * @da: device address * @align: the alignment between the consumer and producer parts of the vring * @num: num of buffers supported by this vring (must be power of two) * @notifyid is a unique rproc-wide notify index for this vring. This notify * index is used when kicking a remote processor, to let it know that this * vring is triggered. * @pa: physical address * * This descriptor is not a resource entry by itself; it is part of the * vdev resource type (see below). * * Note that @da should either contain the device address where * the remote processor is expecting the vring, or indicate that * dynamically allocation of the vring's device address is supported. */ structfw_rsc_vdev_vring { u32 da; u32 align; u32 num; u32 notifyid; u32 pa; } __packed;
/** * struct fw_rsc_vdev - virtio device header * @id: virtio device id (as in virtio_ids.h) * @notifyid is a unique rproc-wide notify index for this vdev. This notify * index is used when kicking a remote processor, to let it know that the * status/features of this vdev have changes. * @dfeatures specifies the virtio device features supported by the firmware * @gfeatures is a place holder used by the host to write back the * negotiated features that are supported by both sides. * @config_len is the size of the virtio config space of this vdev. The config * space lies in the resource table immediate after this vdev header. * @status is a place holder where the host will indicate its virtio progress. * @num_of_vrings indicates how many vrings are described in this vdev header * @reserved: reserved (must be zero) * @vring is an array of @num_of_vrings entries of 'struct fw_rsc_vdev_vring'. * * This resource is a virtio device header: it provides information about * the vdev, and is then used by the host and its peer remote processors * to negotiate and share certain virtio properties. * * By providing this resource entry, the firmware essentially asks remoteproc * to statically allocate a vdev upon registration of the rproc (dynamic vdev * allocation is not yet supported). * * Note: unlike virtualization systems, the term 'host' here means * the Linux side which is running remoteproc to control the remote * processors. We use the name 'gfeatures' to comply with virtio's terms, * though there isn't really any virtualized guest OS here: it's the host * which is responsible for negotiating the final features. * Yeah, it's a bit confusing. * * Note: immediately following this structure is the virtio config space for * this vdev (which is specific to the vdev; for more info, read the virtio * spec). the size of the config space is specified by @config_len. */ structfw_rsc_vdev { u32 id; u32 notifyid; u32 dfeatures; u32 gfeatures; u32 config_len; u8 status; u8 num_of_vrings; u8 reserved[2]; structfw_rsc_vdev_vringvring[]; } __packed;
/** ****************************************************************************** * @file rsc_table.c * @author MCD Application Team * @brief Ressource table * * This file provides a default resource table requested by remote proc to * load the elf file. It also allows to add debug trace using a shared buffer. * ****************************************************************************** * @attention * * Copyright (c) 2021 STMicroelectronics. * All rights reserved. * * This software is licensed under terms that can be found in the LICENSE file * in the root directory of this software component. * If no LICENSE file comes with this software, it is provided AS-IS. * ****************************************************************************** */
/* Since GCC is not initializing the resource_table at startup, it is declared as volatile to avoid compiler optimization * for the CM4 (see resource_table_init() below) */ volatilestructshared_resource_table __resource __attribute__((used)) resource_table; #else CONST structshared_resource_table __resource __attribute__((used)) resource_table = { #endif #elif defined(__ICCARM__) __root CONST structshared_resource_tableresource_table @ ".resource_table" = { #endif
voidresource_table_init(int RPMsgRole, void **table_ptr, int *length) {
#if !defined (LINUX_RPROC_MASTER) #if defined (__GNUC__) && ! defined (__CC_ARM) #ifdef VIRTIO_MASTER_ONLY
/* * Currently the GCC linker doesn't initialize the resource_table global variable at startup * it is done here by the master application. */ memset(&resource_table, '\0', sizeof(struct shared_resource_table)); resource_table.num = 1; resource_table.version = 1; resource_table.offset[0] = offsetof(struct shared_resource_table, vdev);
/* * Copyright (c) 2021 STMicroelectronics. * All rights reserved. * * This software is licensed under terms that can be found in the LICENSE file * in the root directory of this software component. * If no LICENSE file comes with this software, it is provided AS-IS. * */
/* This file populates resource table for BM remote * for use by the Linux Master */
Place the entire resource_table variable into the.resource_tableELF section.
This is exactly the section name that the Linux siderproc_elf_load_rsc_table() / rproc_elf_find_loaded_rsc_table() looks for—when the A7 loads the firmware ELF, it locates the resource table by section name.
resource_table_init() Pass the address and length of this table to the OpenAMP middleware, as the M4’s virtio/rpmsg stack will need them later.
/** * struct fw_rsc_vdev - virtio device header * @id: virtio device id (as in virtio_ids.h) * @notifyid is a unique rproc-wide notify index for this vdev. This notify * index is used when kicking a remote remoteproc, to let it know that the * status/features of this vdev have changes. * @dfeatures specifies the virtio device features supported by the firmware * @gfeatures is a place holder used by the host to write back the * negotiated features that are supported by both sides. * @config_len is the size of the virtio config space of this vdev. The config * space lies in the resource table immediate after this vdev header. * @status is a place holder where the host will indicate its virtio progress. * @num_of_vrings indicates how many vrings are described in this vdev header * @reserved: reserved (must be zero) * @vring is an array of @num_of_vrings entries of 'struct fw_rsc_vdev_vring'. * * This resource is a virtio device header: it provides information about * the vdev, and is then used by the host and its peer remote remoteprocs * to negotiate and share certain virtio properties. * * By providing this resource entry, the firmware essentially asks remoteproc * to statically allocate a vdev upon registration of the rproc (dynamic vdev * allocation is not yet supported). * * Note: unlike virtualization systems, the term 'host' here means * the Linux side which is running remoteproc to control the remote * remoteprocs. We use the name 'gfeatures' to comply with virtio's terms, * though there isn't really any virtualized guest OS here: it's the host * which is responsible for negotiating the final features. * Yeah, it's a bit confusing. * * Note: immediately following this structure is the virtio config space for * this vdev (which is specific to the vdev; for more info, read the virtio * spec). the size of the config space is specified by @config_len. */ METAL_PACKED_BEGIN structfw_rsc_vdev { uint32_t type; // ← ST added type at the very beginning! uint32_t id; uint32_t notifyid; uint32_t dfeatures; uint32_t gfeatures; uint32_t config_len; uint8_t status; uint8_t num_of_vrings; uint8_t reserved[2]; structfw_rsc_vdev_vringvring[0];// Zero-length flexible array } METAL_PACKED_END;
ST’sfw_rsc_vdevfolds type in
There are two points here:
ST adds type at the beginning ofstruct fw_rsc_vdev, while Linux’s struct fw_rsc_vdev does not have type (type is in a separatestruct fw_rsc_hdr). But the two are completely identical on-wire:
ST does this so that a designated initializer can initialize the entire vdev entry (including type) at once.
C trick of zero-length vring[0] plus separate vring0/vring1 members
fw_rsc_vring[0] at the end of vdev occupies 0 bytes, sostruct shared_resource_tablethe vring0 and vring1 members immediately following vdev in memory land right after vdev—exactly where Linux expects to find the vring array. This is equivalent to Linux’s flexible vring[] array, but ST uses separate named members for easier initialization.
/** * struct fw_rsc_vdev_vring - vring descriptor entry * @da: device address * @align: the alignment between the consumer and producer parts of the vring * @num: num of buffers supported by this vring (must be power of two) * @notifyid is a unique rproc-wide notify index for this vring. This notify * index is used when kicking a remote remoteproc, to let it know that this * vring is triggered. * @reserved: reserved (must be zero) * * This descriptor is not a resource entry by itself; it is part of the * vdev resource type (see below). * * Note that @da should either contain the device address where * the remote remoteproc is expecting the vring, or indicate that * dynamically allocation of the vring's device address is supported. */ METAL_PACKED_BEGIN structfw_rsc_vdev_vring { uint32_t da; uint32_t align; uint32_t num; uint32_t notifyid; uint32_t reserved; } METAL_PACKED_END;
/** * struct fw_rsc_trace - trace buffer declaration * @da: device address * @len: length (in bytes) * @reserved: reserved (must be zero) * @name: human-readable name of the trace buffer * * This resource entry provides the host information about a trace buffer * into which the remote remoteproc will write log messages. * * @da specifies the device address of the buffer, @len specifies * its size, and @name may contain a human readable name of the trace buffer. * * After booting the remote remoteproc, the trace buffers are exposed to the * user via debugfs entries (called trace0, trace1, etc..). */ METAL_PACKED_BEGIN structfw_rsc_trace { uint32_t type; uint32_t da; uint32_t len; uint32_t reserved; uint8_t name[RPROC_MAX_NAME_LEN]; } METAL_PACKED_END;
/* Since GCC is not initializing the resource_table at startup, it is declared as volatile to avoid compiler optimization * for the CM4 (see resource_table_init() below) */ volatilestructshared_resource_table __resource __attribute__((used)) resource_table; #else CONST structshared_resource_table __resource __attribute__((used)) resource_table = { #endif #elif defined(__ICCARM__) __root CONST structshared_resource_tableresource_table @ ".resource_table" = { #endif
Device address. If -1, it indicates support for dynamically allocating the device address of the vring.
align
16
16
Alignment size. The number of alignment bytes between the vring consumer and producer parts.
num
16
16
Number of buffers. The number of buffers supported by this vring (must be a power of 2).
notifyid
0 (master→remote)
1 (remote→master)
Notification IDA unique notification index within the entire remote processor (rproc) scope. When sending a kick signal to the remote side, this ID is used to indicate which vring was triggered.
reserved
0
0
Reserved fieldMust be 0.
Dynamic ResMgrThe core of:da = -1
Static method: firmware hardcodesvring.da = 0x10040000, Linux uses it directly.
Dynamic method (STM32CubeMP1/Projects/STM32MP157C-EV1/Applications/OpenAMP/OpenAMP_Dynamic_ResMgr/): firmware writesda = -1, indicating “Linux will allocate”, Linux from the DTvdev0vring0/1reservedcarveoutpool allocates vring memory, and fills back the real address intovring->da. Firmware declares requirements, host allocates and fills back — this is exactly the fw_rsc_“negotiation” mentioned in the vdev comment.
#if defined (__LOG_TRACE_IO_) .num = 2, // resource entry num #else .num = 1, #endif
...
#if defined (__LOG_TRACE_IO_) .cm_trace = { RSC_TRACE, // type = 2 (uint32_t)system_log_buf, // da = M4 log buffer address (note: real address, not -1) SYSTEM_TRACE_BUF_SZ, // len = 2048 (openamp_log.h) 0, // reserved "cm4_log", // name → host debugfs file name }, #endif
Note:
The da of trace is not-1
The trace buffer is allocated by M4 itself (system_log_buf is in M4 memory), host is read-only and does not allocate. After host starts, it will createdebugfs/.../cm4_log, and what it reads is the log written by M4.
voidresource_table_init(int RPMsgRole, void **table_ptr, int *length) {
#if !defined (LINUX_RPROC_MASTER) #if defined (__GNUC__) && ! defined (__CC_ARM) #ifdef VIRTIO_MASTER_ONLY
/* * Currently the GCC linker doesn't initialize the resource_table global variable at startup * it is done here by the master application. */ memset(&resource_table, '\0', sizeof(struct shared_resource_table)); resource_table.num = 1; resource_table.version = 1; resource_table.offset[0] = offsetof(struct shared_resource_table, vdev);
Skip the entire#if !defined(LINUX_RPROC_MASTER)block; the table is already initialized at compile time, the function only returns: table_ptr = (void *)&resource_table length = sizeof(sizeof(resource_table))
GCC + M4 as master
GNUC && !LINUX_RPROC_MASTER && VIRTIO_MASTER_ONLY
GCC does not initialize global variables with section attributes at startup, somemsetafter clearing, fill field by field at runtime
GCC + M4 as slave
GNUC && !LINUX_RPROC_MASTER
while(vring1.da != VRING_RX_ADDRESS){}spin waiting for master to fill the table
This set of#ifnesting is for OpenAMP to be compatible withLinux-master / M4-master / M4-slavethree topologies. For STM32MP157 (Linux master), the runtime part is not compiled, it actually only returns a pointer*length = sizeof(resource_table);and*table_ptr = (void *)&resource_table;。
three#ifbranches indicate who fills the table for this M4 code under the three topologiesresource_table: Linux loads (static), M4 master fills at runtime, M4 slave waits to be filled.
Summary
resource_table
Thisrsc_table.cThis is the “resource requirement list” submitted by the M4 firmware to Linux:
a trace buffer, and set the vring address to -1 (FW_RSC_ADDR_ANY) to let Linux dynamically allocate—this is exactly whatDynamic ResMgrmeans.
The entire table is placed in the.resource_tableELF section, initialized at compile time,resource_table_init()just passes the pointer to the OpenAMP middleware.
Storage and System Resource Allocation
reserved-memory
In thestm32mp157d-atk.dtsidevice tree, you can see this code:
reserved-memoryindicates that the memory allocated under this node is reserved memory,reserved memory regions are generally used by specific drivers, and they differ from the memory regions used by the Linux kernel. Typically, reserved memory functions are closely related to the Linux kernel’s DMA or CMA.
If a node’scompatiblethe attribute isshared-dma-pool, it indicates that the memory region of this node is used as a DMA buffer shared pool for a group of devices. At this point, if the node attribute containsno-map, it means that this memory cannot be mapped as part of system memory by the Linux kernel and needs to be separated from system memory. If the node attribute containsreusableattribute, it means that this memory does not need to be separated from system memory, and when specific drivers are not using this memory, the OS can use it.
Note that a node cannot have both the no-map and reusable attributes, as they are logically contradictory.
We see thatreserved-memoryeach child node under theno-mapattribute, indicating that this memory cannot be used as system memory by the Linux kernel and is actually reserved for the M4 system.
0x10000000 is the starting address of SRAM1, and the size of 0x40000 is exactly 256KB. This area is the SRAM1+SRAM2 region, mainly used to store the code and data segments of the M4 firmware: SRAM1 (code) and SRAM2 (data). This can be seen from the M4 project’s linker script, but the address range can also be redefined by modifying the linker script. However, note that the address range in the linker script must be consistent with the range configured in the device tree.
vdev0vring0、vdev0vring1andvdev0bufferchild nodes are exactly at SRAM3, i.e., the IPC buffer. The allocation of these three nodes is as follows:
vdev0vring0child node, 0x10040000 is the starting address of vring0, with an address length of 0x1000, i.e., 4KB. Similarly,
vdev0vring1is the starting address of vring1, also with an address length of 0x1000, i.e., 4KB. These two nodes are the vrings we mentioned earlier for sending and receiving messages.
vdev0bufferchild node, with a starting address of 0x10042000, an address length of 0x4000, and a size of 16KB. This address falls within SRAM3, and this is the configured shared memory region.
vdev0vring0、vdev0vring1andvdev0bufferOnly the first 24KB of SRAM3 is occupied; SRAM3 has 64KB and is not fully used. Therefore, if needed, the unused addresses of SRAM3 can be repurposed for other functions by modifying the device tree and linker script.
mcuramThe child node’s starting address is 0x30000000, with an address length of 0x40000 and a size of 256KB. This address range corresponds to the SRAM1 and SRAM2 areas in RAM aliases. Since the physical addresses of RAM aliases and SRAMs are the same, it is also necessary to configure the corresponding region that is “visible” to the A7; this region corresponds to the one “visible” to the M4.mcuram2region. Because mcuramandmcuram2 have the same physical address, the functions of these two memory regions are identical. It can be said that mcuram is an alias memory region of mcuram2. This may be the origin of “aliases” in RAM aliases. Note that in the device tree,mcuramandmcuram2the memory segment definitions must be consistent.
retramThe child node’s starting address is 0x38000000, with an address length of 0x10000 (64KB), belonging to the RETRAM area in RAM aliases. This area corresponds to the RETRAM area in the BOOT storage region, and they share the same physical address. RETRAM is used to store the interrupt vector table of the M4 core (the interrupt vector table starts at 0x00000000). By default, the RETRAM starting address is 0x38000000, and it is remapped to 0x00000000 to execute M4 code.
Summary
SRAM Address Allocation
Child Node
Address
Size
Region
mcuram2
0x10000000~0x10040000
256KB
M4-visible SRAM1+SRAM2
vdev0vring0
0x10040000~0x10041000
4KB
SRAM3
vdev0vring1
0x10041000~0x10042000
4KB
SRAM3
vdev0buffer
0x10042000~0x10046000
16KB
SRAM3
mcuram
0x30000000~0x30040000
256KB
A7 visible SRAM1+SRAM2
retram
0x38000000~0x38010000
64KB
A7 visible RETRAM
For unified address management, A7 and M4 may have different address mappings for the same physical address of a real chip. For example, A7 starts from 0X38000000 and this part is called mcuram, while from M4’s perspective it starts from 0X10000000 and this part is called mcuram2. However, these two addresses and their covered lengths ultimately point to the same real memory chip.
In the above device tree node, there is am4_system_resourceschild node (i.e., M4’s resource manager), which is used to configure M4’s peripheral resources, wherecompatiblein the attributerproc-srm-corewill match the kernel source code’sdrivers/remoteproc/rproc_srm_core.cdriver file, as follows is therproc_srm_core.cpartial code of the file:
After the device and driver match successfully, the function represented by the probe member variable of platform_driverrproc_srm_core_probe()is executed, through which the rproc child device is registered (rproc represents a physical remote processor device, which can be considered a peripheral)
kernel source code’sstm32mp157-m4-srm.dtsidevice tree file, as follows,&m4_rprocindicates in the precedingm4_rprocAppend content under the node:
The above codeconfigures the system resources of M4, i.e., which peripherals M4 has configured, howeverstatusthe attributes are alldisabled, meaning although peripherals are configured, they are not enabled.
stm32mp157d-atk.dtsThe file also includesstm32mp157d-atk.dtsithe file
So you can directly in thestm32mp157d-atk.dtsiorstm32mp157d-atk.dtsdevice tree file choose to enable a certain peripheral of M4.
M4 and A7 share some peripherals, for example, GPIO is a shared resource. If this GPIO is not multiplexed for other functions and is simply used as a regular IO, then both A7 and M4 can access these resources. For example, instm32mp157d-atk.dtsia buzzer and two LED nodes are configured, which use GPIO functions. These nodes are for A7, but M4 can also use them:
If it is a peripheral with exclusive function, meaning these peripherals can only be used by A7 alone or by M4 alone, if both A7 and M4 use the peripheral together, there will be a resource contention issue, and one side will experience an anomaly (the main processor has a certain priority, and the anomaly usually occurs on the coprocessor side). For example, if A7 and M4 both occupy ADC1 to collect data, the data collected by M4 will be inaccurate, and it may not collect data and display 0.
For exclusive peripherals:
If A7 wants to use this peripheral, the corresponding peripheral node for A7 must be configured in the device tree
If this peripheral is to be used by M4, it is not necessary to configure M4-related nodes in the device tree; you only need to configure the peripheral in the firmware (i.e., configure it in the bare-metal program). After A7 loads and starts the firmware, M4 can use the peripheral.
If a peripheral node for A7 has already been configured in the device tree, and M4 wants to use this peripheral, it is best to comment out the relevant nodes occupied by A7 in the device tree. For example, instm32mp157d-atk.dtsithe device tree has the following nodes:
The above code snippet indicates that ADC1 is allocated to A7. If M4 wants to use it, this code does not need to be commented out, as long as it is ensured that A7 does not operate ADC1 after the Linux system runs. Then, after loading and running the M4 firmware (where ADC1 has been configured), M4 can use ADC1 to collect data.
However, if A7 operates ADC1 at this time, the data collected by ADC1 on the M4 side will be inaccurate. Therefore, it is recommended to comment it out:
That is, comment out the ADC1 part occupied by A7. The following &m4_adc node part is manually added; this part can be added or not, but according to ST’s standard, it is best to add it. The device treestm32mp157c-dk2-m4-examples.dtsis a template file. When modifying the device tree, you can refer to the template file. The above modified&m4_adcnode is written by referring to this file.
After modifying the device tree, execute the following command to recompile the device tree:
1
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- dtbs
Then copy the compiledstm32mp157d-atk.dtbfile to the/bootdirectory of the development board’s file system, replace the previous device tree binary file, then execute the sync command to synchronize the cache, and restart the development board. After re-entering the Linux operating system, the A7 can no longer operate ADC1. When the M4 firmware is loaded and started, the M4 can access ADC1 independently.
Linker Script
Linker Script Syntax
Entry Address
1 2
/* Entry Point */ ENTRY(Reset_Handler)
ENTRY(SYMBOL), which means setting the value of the symbol SYMBOL as the entry address, i.e., the address of the first instruction executed by the program.
Memory Region Definition
By default, the linker can allocate storage regions at arbitrary positions for sections. The MEMORY command can be used to describe which memory regions can be used by the linker and which should be avoided. A linker script can contain at most one MEMORY command.
1 2 3 4 5 6
MEMORY { /* Name Attributes Origin Length */ NAME [(ATTR)] : ORIGIN = ORIGIN, LENGTH = LEN }
NAMEis the name used to reference the memory region in the linker script, each memory region has a unique name
ORIGINis the starting address
LENGTHis the length of the address
ATTR: an optional attribute string used to restrict which input sections can be placed in this region. Supported characters include:
r: Read-only section
w: Read/Write section
x: Executable section
a: Allocatable section
iorl: Initialized section
!: Inverted attribute (indicates placing sections that do not satisfy any attribute after this character)
Usage: Once a memory region is defined, it can be used in section descriptions with>regionto instruct the linker to place a specific output section into that region.
1 2 3 4 5 6 7
SECTIONS { .text : { *(.text) } > mem }
Section Link Definition
The SECTIONS command is a very important command in linker scripts. Its function is:Tell the linker how to map input file sections to output file sections, and how to place output sections into the address space.。
Like the MEMORY command, there is only one SECTIONS command in a linker script. If there is no SECTIONS command in the entire linker script, the linker will combine all input sections with the same name into one output section, and the order of input sections will be the order in which they are discovered by the linker.
. = ALIGN(4): Indicates 4-byte address alignment. That is, the starting address of the section must be divisible by 4. Common alignments are ALIGN(4) or ALIGN(8), meaning 4-byte or 8-byte alignment.
PROVIDEandPROVIDE_HIDDENKeyword: defines a symbol in the linker script that is not defined by the object file but is referenced by it.
KEEP(): The function of KEEP() is that when the linker’s–gc-sectionsgarbage collection option is enabled, this part cannot be collected. For example,KEEP(*(.text))indicates that not all .text sections can be treated as garbage for collection.
/DISCARD/: is a special section name; if used as the output section, all matching sections are discarded.
For more linker script syntax, refer to this site:
/* Symbols needed for OpenAMP to enable rpmsg */ __OPENAMP_region_start__ = ORIGIN(m_ipc_shm); __OPENAMP_region_end__ = ORIGIN(m_ipc_shm)+LENGTH(m_ipc_shm);
/* Sections */ SECTIONS { /* The startup code into ROM memory */ /* Interrupt vector table, placed in RETRAM */ .isr_vector : { . = ALIGN(4); KEEP(*(.isr_vector)) /* Startup code */ . = ALIGN(4); } > m_interrupts
/* The program code and other data into ROM memory */ .text : { . = ALIGN(4); *(.text) /* .text sections (code) */ *(.text*) /* .text* sections (code) */ *(.glue_7) /* glue arm to thumb code */ *(.glue_7t) /* glue thumb to arm code */ *(.eh_frame)
KEEP (*(.init)) KEEP (*(.fini))
. = ALIGN(4); _etext = .; /* define a global symbols at end of code */ } > m_text
/* Uninitialized data section into RAM memory */ . = ALIGN(4); .bss : { /* This is used by the startup in order to initialize the .bss secion */ _sbss = .; /* define a global symbol at bss start */ __bss_start__ = _sbss; *(.bss) *(.bss*) *(COMMON)
. = ALIGN(4); _ebss = .; /* define a global symbol at bss end */ __bss_end__ = _ebss; } > m_data
/* User_heap_stack section, used to check that there is enough RAM left */ ._user_heap_stack : { . = ALIGN(8); PROVIDE ( end = . ); PROVIDE ( _end = . ); . = . + _Min_Heap_Size; . = . + _Min_Stack_Size; . = ALIGN(8); } > m_data
/* Remove information from the compiler libraries */ /DISCARD/ : { libc.a ( * ) libm.a ( * ) libgcc.a ( * ) }
/* Symbols needed for OpenAMP to enable rpmsg */ __OPENAMP_region_start__ = ORIGIN(m_ipc_shm); __OPENAMP_region_end__ = ORIGIN(m_ipc_shm)+LENGTH(m_ipc_shm);
Core Configuration Analysis
Program Entry: SpecifiesReset_Handleras the program entry; this function is defined in the startup filestartup_stm32mp15xx.s.
Stack Top Address: Set the highest stack address to0x10040000. It determines the initial position of the stack pointer (SP), corresponding to the mapping boundary of the internal SRAM.
Stack size: Specify the minimum space. The heap size is512B, the stack size is1KB。
Memory region (MEMORY) definition
m_interrupts(0x00000000 ~ 0x00000298): Mapped to the RETRAM region, used to store the interrupt vector table of the M4 core.
m_text (0x10000000 ~ 0x10020000): Corresponds to SRAM1 (128KB), used to store the code segment.
m_data (0x10020000 ~ 0x10040000): Corresponds to SRAM2 (128KB), used to store the data segment.
The linker script plans the program execution address in SRAM:
SRAM allocation logic under dual-core collaboration
The total SRAM space available to M4 isSRAM1 ~ SRAM4 (384KB total), address range0x10000000 ~ 0x1005FFFF. When allocating, pay attention to the operating mode:
Single-core mode (M4 only): SRAM1 ~ SRAM4 can be fully allocated to M4.
Dual-core mode (A7 + M4)：
SRAM1 & SRAM2: Fully allocated to M4 (stores M4 code and data).
SRAM3: Shared by A7 and M4. Among them,0x10040000 ~ 0x10046000is used by default asthe memory swap area for dual-core communication (IPC Shared Memory). The specific allocation ratio needs to refer to the Device Tree configuration under Linux.
And m_interrupts is actually in RETRAM, what is the remaining SRAM4 used for?
If not running the Linux operating system, but only running M4 bare-metal programs, the M4 core can fully use this area, as specified by the user.
If running the Linux operating system, under the Linux device tree, SRAM4 is already used by default as DMA for Linux functions. To release this area, delete the corresponding node in the device tree (but this is not recommended, as the A7 may malfunction).
Several SRAM areas
Based on the above analysis, the summary is as follows:
If not running A7, only running M4 (M4 can run bare metal, RTOS): SRAM1~SRAM4 can be fully allocated to M4;
If running both A7 and M4 (e.g., dual-core communication): SRAM1 and SRAM2 are exclusively for M4, part of SRAM3 is shared between M4 and A7, and SRAM4 is configured separately for DMA under Linux, meaning it is occupied by A7. If you need to modify the address range in MEMORY, be sure to refer to the address range of the memory map table for modification.
]]>This article introduces the structure and function of the resource table in the remote processor firmware image, detailing how the main processor, after loading the firmware, decodes the resource table to allocate system resources such as physical memory, configure Virtio devices, and create RPMsg channels for inter-core communication. Additionally, using the STM32MP15C reference code, it summarizes the specific definitions of resource entries under the Remoteproc framework and the implementation of dynamic resource management based on OpenAMP.OpenAMPhttps://even629.com/en/posts/202607040/2026-07-04T08:17:13.000Z2026-07-04T08:17:13.000Z Timeline
Timeline
2026-07-04
init
This article introduces the background of the OpenAMP open asymmetric multiprocessing software framework and its application in multi-core heterogeneous systems. It discusses in detail the three core components: Virtio, RPMsg, and Remoteproc, and summarizes the specific working mechanism for lifecycle management and message communication between the Linux main processor and bare-metal or RTOS coprocessors based on shared memory and inter-core interrupts.
OpenAMP (Open Asymmetric Multiprocessing) was originally developed by Mentor Graphics and Xilinx as a software framework to enable communication between RTOS or bare-metal programs and the Linux interface in AMP systems. Currently, OpenAMP is available on platforms such as ST, NXP, TI, and Xilinx. These manufacturers have provided ported OpenAMP development examples, and users can refer to these examples for development. This article usesSTM32Cube_FW_MP1_V1.2.0\Projects\STM32MP157C-DK2\Applications\OpenAMPas a reference example.
OpenAMP provides implementations of RPMsg, VirtIO, and RemoteProc:
virtio
Virtio is a virtual device framework that provides shared memory management. The vring in Virtio is a FIFO queue of pointers to data buffers, with two unidirectional vrings:
One vring is dedicated to messages sent to the remote processor
The other vring is used for messages received from the remote processor
The two vrings form a ring. Data between the A7 and M4 is shared through the vring buffers, which are the shared memory of the two processors (also known as IPC Buffers or Vring buffers)
In the reference configuration provided by ST, the shared memory of the STM32MP157 is located in SRAM3. As shown in the figure below, the processors complete data forwarding through the vring ring buffer. Virtio vring data forwarding
The relevant code is located atlinux-5.10.256/drivers/virtio
rpmsg
The RPMsg framework is shown in the figure below. It can be seen that the RPMsg framework sits on top of Virtio. RPMsg (Remote Processor Messaging) framework is a message bus based on Virtio. RPMsg can communicate messages with the remote end via Virtio under the coordination of IPCC, while Remote proc can write firmware to the remote end under the control of IPCC, or control the lifecycle, status, etc. of the remote end.
Schematic diagram of the Rpmsg framework
From the figure, it can be seen that OpenAMP uses IPCC at the bottom layer. Reference:
On Cortex-A7, the RemoteProc framework activates Linux-based inter-process communication (IPC) based on available information in the coprocessor’s firmware resource table. The RPMsg service is implemented through the RPMsg framework, and the mailbox service is implemented by the mailbox driver stm32_ipcc.
On Cortex-M4, the RPMsg service is implemented by the OpenAMP library, and the mailbox service is implemented by the HAL_IPCC driver.
This is a bit convoluted. The general idea is that the A core running Linux and the M core running bare metal or FreeRTOS communicate via OpenAMP. The A core and M core have correspondingly designed OpenAMP, but they are compatible with each other, only the underlying calls differ, such as the A core’s mailbox driver stm32_ipcc implementation, and the M core’s mailbox service is implemented by HAL_IPCC driver.
In the default configuration provided by ST, the SRAM3 area in MCUSRAM has two vrings, one for sending and one for receiving messages. The vring buffers are the shared memory. The RPMsg framework is based on Virtio’s vrings. It sends messages to or receives messages from the remote processor through Virtio’s vrings. When a new message is already in the shared memory, the mailbox framework notifies the processor that there is a message to receive.
RPMsg is actually a message bus based on Virtio, used to implement message passing (transferring inter-core data). RPMsg can be considered a channel for communicating with a remote processor. This channel can also be called an RPMsg device. Each channel has a local source address and a remote destination address, and messages can be transmitted between the source and destination addresses. The communication process is shown in the figure below:
Based on these software frameworks, all data is transmitted over RPMsg. RPMsg transfers data to the RPMsg client in the kernel layer, and then to user space through device nodes under the kernel. In relation to the hierarchical structure of the network TCP/IP, shared memory and inter-core interrupts correspond to the physical hardware layer, Virtio corresponds to the MAC sublayer, and RPMsg corresponds to the transport layer, as shown in the following figure:
RPMsg analogy to TCP/IP structural relationship
remoteproc
For SOCs with asymmetric multiprocessing, different cores may run different operating systems. For example, the Cortex-A7 of the STM32MP157 runs the Linux operating system, while the Cortex-M4 can run the OneOS operating system or bare-metal programs.
To facilitate easy communication between the main processor running Linux and the coprocessor, the Remoteproc inter-core communication framework was introduced after Linux version 3.4.X. The Remoteproc framework was developed by Texas Instruments, and based on it, Mentor Graphics developed a software framework called OpenAMP. Under this framework, the Linux operating system on the main processor can manage the lifecycle of the remote processor and its associated software environment, i.e., start or shut down the remote processor.
Let’s take the STM32MP157 as an example to look at the Remoteproc framework for M4 and A7, as shown in the following figure:
Remoteproc framework
Remoteproc is part of the generic remote processing framework, and its functions are:
A7 loads the code and data segments of the M4 firmware image into M4 memory for in-place program execution;
Parse the firmware resource table to set associated resources (information such as the starting address and size of each segment in the firmware, Virtio device features, vring address, size, and alignment information);
Control the start and shutdown of the M4 core firmware;
Establish RPMsg communication channels for communication with M4;
Provide monitoring and debugging remote services (using sysfs and debugfs file systems, which are already configured by default in the development board’s Linux file system and are ready to use on boot).
Note: RPMsg communication uses Mailbox, but this is not well illustrated in the figure. Therefore, the general process can be understood as: Remoteproc can directly map the firmware to the M core, and message passing requires communication through channels established after initialization. In the figure, RCC and others are configured automatically via stm32 after the firmware image._rproc will automatically configure, i.e., stm32_rproc is the post-sales of Remoteproc, performing a series of subsequent operations.
stm32_rproc is the driver for the remote processor (M4 core), and its role is:
Register vendor-specific functions (such as callback functions) with the Remoteproc framework;
Handle platform resources associated with the M4 (such as registers, watchdog, reset, clock, and memory);
Forward notifications to the M4 via the Mailbox framework.
The firmware mentioned above is the executable file for the M4, such as the one compiled under MDK.axffile or the one compiled under STM32CubeIDE.elffile.
The A7 is called the main processor, and the M4 is called the coprocessor or remote processor. The main processor starts first, then boots the coprocessor:
The main processor can first load the coprocessor’s firmware via the Remoteproc framework, then parse the information published in the firmware resource table to configure the coprocessor’s system resources and create Virtio devices.
Once the Remoteproc on the main processor loads and starts the remote processor’s firmware, the coprocessor begins to run.
After the coprocessor starts, inter-core communication between the two cores is not yet possible. An RPMsg channel must first be created, and only after the main processor sends the first message can inter-core communication occur and data be exchanged.
If the firmware needs to be stopped, the main processor can also shut down the firmware, and the coprocessor program will then stop running. In summary, the Remoteproc framework implements lifecycle management (LCM) and control of the remote coprocessor, as shown in the following diagram:
Remoteproc controls the coprocessor
The relevant code is located atlinux-5.10.256/drivers/remoteproc
Summary
Based on the above analysis, the OpenAMP open-source software framework has the following functions and features:
Provides remote processor lifecycle management and inter-processor communication functions;
Provides independent libraries usable in RTOS and bare-metal software environments;
Compatible with upstream Linux Remoteproc, RPMsg, and VirtIO components.
The process of implementing inter-core communication using OpenAMP:
Assume the main processor is already running and the remote processor is in a certain state, such as standby or powered off.
The main processor, based on the Remoteproc framework, first loads the firmware of the remote processor into memory.
Then the main processor starts the remote processor (runs the firmware) and waits for it to complete initialization, such as waking up, de-asserting reset, powering on, etc.
After the remote processor completes initialization, it notifies the main processor.
The main processor and the remote processor establish an RPMsg communication channel.
Through the RPMsg channel, the two can perform inter-core communication.
]]>This article introduces the background of the OpenAMP open asymmetric multiprocessing software framework and its application in multi-core heterogeneous systems. It discusses in detail the three core components: Virtio, RPMsg, and Remoteproc, and summarizes the specific working mechanism for lifecycle management and message communication between the Linux main processor and bare-metal or RTOS coprocessors based on shared memory and inter-core interrupts.IPCChttps://even629.com/en/posts/202607020/2026-07-02T15:17:13.000Z2026-07-02T15:17:13.000Z Timeline
Timeline
2026-07-02
init
This article introduces the working principle of the IPCC (Inter-Processor Communication Controller) hardware module in the STM32MP157, discusses its process of achieving signal notification between the Cortex-A7 and Cortex-M4 cores through shared memory and hardware interrupt mechanisms, and summarizes the channel allocation, software framework application, and related register configuration of the IPCC.
IPC（ Inter -Process Communication, inter-process communication) refers to the interaction between data of two processes (in a broad sense, including processes on heterogeneous cores), which is achieved through the inter-processor communication controllerIPCC（Inter-Process Communication controller, IPC controller). The IPCC is a hardware component used for signal exchange between two CPUs. Mailboxes rely on the IPCC. The IPCC hardware module of the STM32MP157 has 6 bidirectional channels, each divided into two sub-channels, resulting in a total of 12 sub-channels. The figure shows a structural diagram of communication between the A7 core and M4 core via the IPCC.
IPC Communication Structure Diagram
When a data packet is placed into shared memory, the CPU needs to interrupt or “notify” the other CPU that there is a new data packet in shared memory to be processed. The other CPU then processes it upon receiving the signal. This is accomplished using the IPCC hardware interrupt mechanism.。
The interrupt controller for the A7 core is the GIC, and for the M4 core it is the NVIC. The role of the IPCC is like a sentinel, controlling when data can be received and when data can be sent; the entire process is managed by the IPCC.
The IPCC only provides a mechanism for information exchange between processors; it does not have data transmission functionality., that is,the data to be exchanged between processorsis not transmitted within the IPCC,but is transmitted in shared memory.。
IPCC Channels
The working modes of the IPCC’s 6 communication channels can be divided into simplex, half-duplex, and full-duplex:
There are 6 channels in the direction from CPU1 to CPU2 (P1_TO_P2 sub-channels, P1 represents CPU1, P2 represents CPU2)
There are 6 channels in the direction from CPU2 to CPU1 (P2_TO_P1 sub-channels, P1 represents CPU1, P2 represents CPU2)
As shown in the table below, in the ST official IPCC communication model, these 6 channels are used as different software frameworks, where:
Channel 3 is in simplex mode and is used as the RemoteProc framework, through which the main processor can load the firmware of the coprocessor and control the lifecycle of the coprocessor;
Channel 2 is in full-duplex mode and is used as the RPMsg framework to transmit messages from A7 to M4;
Channel 1 is in full-duplex mode and is used as the RPMsg framework to transmit messages from M4 to A7.
Channel
Mode
Usage
Software client framework: Cortex-A7 (non-secure)
Software client framework: Cortex-M4
Channel 1
Full-duplex
RPMsg transfer from Cortex-M4 to Cortex-A7: 1. Cortex-M4 uses this channel to indicate a message is available 2. Cortex-A7 uses this channel to indicate the message has been processed
RPMsg framework
OpenAMP
Channel 2
Full duplex
RPMsg transfer from Cortex-A7 to Cortex-M4: 1. Cortex-A7 uses this channel to indicate a message is available 2. Cortex-M4 uses this channel to indicate the message has been processed
RPMsg framework
OpenAMP
Channel 3
Simplex
Cortex-M4 shutdown request
RemoteProc framework
CprocSync cube utility
Channels 4/5/6
Unused
Simplex Communication: Refers to signal transmission in only one direction, capable only of sending or receiving
Half-Duplex Communication: Signals can be transmitted in both directions, but only sending or receiving is allowed at any given moment (single bus and I2C are both half-duplex communication)
Full-Duplex Communication: Full-duplex communication means data is transmitted in both directions simultaneously
It can be seen that in the framework configured by ST:
The RemoteProc software framework solves the lifecycle issue of remote processors
The RPMsg software framework solves the inter-core communication problem
These two are the concerns in multi-core processor communication!
Under the Linux kernel, ST has already ported the RemoteProc and RPMsg software frameworks. The OpenAMP library used by M4 also has corresponding RemoteProc and RPMsg software frameworks. M4 mainly relies on the existing software framework in the OpenAMP library to communicate with A7.
Note: To facilitate the main core in controlling the coprocessor, the OpenAMP framework was designed on the Linux side. However, to be compatible with the Linux-side OpenAMP framework, M4-related manufacturers also designed an OpenAMP framework. The two are interoperable, but there are still some differences, though they share the same name.
The A7 and M4 of STM32MP157 actually transmit data through Channel 1 and Channel 2:
Data transmission between Cortex-A7 and Cortex-M4
IPCC Register
There are 8 registers related to IPCC. The register area is divided into two regions, each occupied by one processor to prevent read-write access conflicts. As shown in the table below, the first 4 registers are occupied by Processor 1, and the last 4 registers are occupied by Processor 2.
IPCC provides dedicated interrupts for processors. Each processor has its own status mask register bits and set or clear register bits for each channel.
Bits 22~31 and bits 6~15: Reserved bits, must be kept at reset value.
Bits 1621,**CH1FM**CH6FM, processor 1 transmit (TX) channel X idle interrupt mask bit, associated withIPCC_C1TOC2SR.CHxF, when this bit is:
1: Transmit (TX) channel X idle interrupt is masked;
0: The transmit (TX) channel X idle interrupt is not masked.
Bits 0 and 5,CH1OMCH6OM, the processor 1 receive (RX) channel X occupied interrupt mask bit, associated withIPCC_C2TOC1SR.CHxF, when this bit is:
1: The receive (RX) channel X occupied interrupt is masked;
0: The receive (RX) channel X occupied interrupt is not masked.
IPCC_C1SCR
IPCC Processor 1 Status Set Clear Register
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
Res
Res
Res
Res
Res
Res
Res
Res
Res
Res
CH6FM
CH5FM
CH4FM
CH3FM
CH2FM
CH1FM
rw
rw
rw
rw
rw
rw
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Res
Res
Res
Res
Res
Res
Res
Res
Res
Res
CH6OM
CH5OM
CH4OM
CH3OM
CH2OM
CH1OM
rw
rw
rw
rw
rw
rw
Bits 22 to 31 and bits 6 to 15 are reserved bits and must be kept at their reset value.
Bits 16 to 21, CH1S to CH6S, processor 1 transmit (TX) channel X status set bits, associated withIPCC_C1TOC2SR.CHxF, when this bit is set:
1: The processor 1 transmit (TX) channel X status bit is set, i.e., CHnF is set to 1, indicating the channel is occupied;
0: No action.
Bits 0 to 5, CH1C to CH6C, processor 1 receive (RX) channel X status clear bits, associated withIPCC_C2TOC1SR.CHxF, when this bit is set:
1: The processor 1 receive (RX) channel X status bit is cleared;
0: No action
IPCC function description
IPCC’s control of processor communication is actually implemented through interrupts, called inter-processor interrupts (IPI). Each processor has two interrupt lines, which are:
One is used for RX channel occupancy (the sending processor publishes data);
One is used for TX channel idle (the receiving processor reads communication data).
Each channel has interrupt masking:
Channel occupancy mask (bit CHnOM);
Channel idle mask (bit CHnFM).
In the context of computers, microcontrollers, or hardware peripherals (such as DMA, Mailbox, IPCC and other communication controllers),“Mask” means to “turn off” or “filter out” a certain interrupt signal, preventing it from being reported to the CPU.。
Each sub-channel has two working modes:
Simplex mode (each channel has its own communication data storage location);
Half-duplex mode (a single channel associated with a bidirectional communication data information storage location).
The communication data is located in shared memory (note that shared memory is not part of the IPCC). Each communication, the IPCC module provides achannel status flag bit CHnF(n can take values 1 to 6, indicating the corresponding channel):
When CHnF=0, it indicates that the relevant channel is idle.(It can also be considered that the communication data has been read by the receiving processor, and the channel is now in an idle state),At this point, the sending processor can occupy this channel to send data;
When CHnF=1, it indicates that the relevant channel has been occupied.(i.e., the communication data has been published by the sending processor),At this point, the receiving processor can access the channel to read the data.
IPCC provides a non-blocking signaling mechanism for channel management:
Message availability interrupt;
Channel flow control (e.g., generating a TX channel idle interrupt is called flow open, and when the channel is occupied, it is called flow close).
Applications benefit from non-blocking interrupt-based message exchange and channel flow control for inter-core communication, with each sub-channel having a transmission direction:
Sent from CPU1 and received by CPU2;
Or sent from CPU2 and received by CPU1.
Simplex transmission mode
The following figure shows a schematic diagram of the IPCC simplex transmission mode.
When the channel status flag indicates channel occupied (CHnF=1), this is because the receiver has not released the channel from the previous message. At this point, the channel idle interrupt is unmasked, and then the TX idle interrupt is awaited.
Once the receiver releases the channel, a channel idle interrupt is generated (stream open). When the channel idle interrupt occurs, the channel idle interrupt is masked, and the message can be written to the data buffer. Subsequently, the channel status flag is set to occupied, which triggers the channel occupied interrupt at the receiver.
Simplex transmission
Simplex reception mode
The following diagram shows the IPCC simplex transmission mode schematic. When a channel occupied interrupt occurs, the receiver determines which channel is occupied and masks the corresponding channel occupied interrupt. Subsequently, data can be read from the shared memory. Once the data is read, the channel status flag CHnF is cleared (CHnF=0), and the channel occupied interrupt is unmasked.
Simplex reception
Half-duplex transmission mode
The following diagram shows the IPCC half-duplex transmission mode schematic.
The half-duplex process allows using a single shared buffer to transmit a message from the sender to the receiver, and then send a response (response pending) from the receiver back to the sender.
Sender data transmission process:
The software variable response pending=1 indicates that the sender is waiting for a response from the receiver.
response pending=0 indicates that a response from the receiver has been obtained.
First, the sender checks the channel status flag. If the channel status flag indicates the channel is occupied (CHnF=1), meaning the receiver has not yet sent a response to the previous message, the sender waits for the response. If the channel is idle, the sender can write the message into the shared memory.
Subsequently, the channel status flag is set to occupied, which triggers the RX channel occupied interrupt at the receiver. Once the channel status flag CHnF=1, the channel idle interrupt is unmasked. The channel idle interrupt indicates whether the response sent by the receiver is available. When the channel idle interrupt occurs (response ready), the sender determines which channel to release and masks the corresponding channel idle interrupt. Then, the response can be read from the shared memory.
Receiver response process:
The receiving processor waits for the software variable response pending to be equal to 1. If it is equal to 1, the receiver writes the response into the shared memory (publishes the response). Once the response is published, the channel status flag CHnF is cleared by CHnC, so CHnF becomes 0, and the receiver unmasks the channel occupancy interrupt (CHnOM = 0).
Half-duplex transmission mode
Half-duplex reception mode
The following figure shows a schematic diagram of the IPCC half-duplex reception mode.
Receiver reads data: When a channel occupancy interrupt occurs, the receiver determines which channel is occupied and masks the corresponding channel occupancy interrupt, then receives data from the shared memory. The channel is released only after the receiver sends the response to the shared memory.
Sender reads response: To receive the response, the channel idle interrupt is unmasked. The sending processor checks which channel becomes idle, masks the relevant channel idle interrupt, and then reads the response from the shared memory.
IPCC half-duplex reception
IPCC provides a non-blocking signaling mechanism for 6 bidirectional channels to atomically publish and retrieve communication data. The non-blocking method allows processors to exchange information in a non-blocking manner, such as reading data. When conditions are not met and results cannot be obtained immediately, the process is suspended, and then periodically checked to see if conditions are met. If met, a read operation is performed; if not, no read is performed. This is the non-blocking method.
The communication process described above can be represented by the following figure. All communicating processors can access the shared memory. Around the shared memory, an interrupt line can be configured from the main processor to the coprocessor and from the coprocessor to the main processor, i.e.,Inter-processor interrupt (PPI, referred to as core interrupt), the initiator of the core interrupt first writes the message data to the shared memory, then initiates the inter-processor interrupt. The interrupted core thread reads the shared memory in the interrupt service routine to obtain the data notified by the initiator.
Shared memory and inter-processor interrupt
Mailbox framework
The Mailbox framework is closely related to IPCC. Mailbox is a driver architecture that relies on the hardware platform for implementation. For example, the Mailbox on the STM32MP157 platform depends on the IPCC peripheral. Its Mailbox framework is shown in the following figure: (Mailbox is a tool for message transmission, relying on IPCC at the bottom layer, but IPCC does not transmit data. Mailbox, based on IPCC, can transmit message data.)
Mailbox framework
How does the upper-layer application know that data has been completely sent or received? This task is handled by the Mailbox framework. The implementation of Mailbox is divided into the Mailbox controller and the Mailbox client:
The mailbox controller is mainly responsible for configuring and handling message queues or interrupt requests (IRQ) from the IPCC peripheral, and provides a common API for mailbox clients responsible for sending or receiving notification messages.
The mailbox client is mainly responsible for sending or receiving notification messages. It sends or receives notification messages through the channel provided by the mailbox controller, which is the IPCC channel.
Users can define their own mailbox client. As shown in the figure above, the mailbox controller under Linux isstm32_ipcc, which configures and controls the IPCC peripheral and can provide mailbox services.stm32_rprocis the remote processor platform driver. It mainly handles platform resources associated with the remote processor (such as registers, watchdog, reset, clock, and memory), can register corresponding callback functions into the Remoteproc framework, and can also forward notification messages to the remote processor through the mailbox framework.
The general workflow of the mailbox framework is:
First, register the mailbox controller;
Before the mailbox client sends data, it first requests a channel;
The client sends data;
The mailbox client records the data;
The mailbox controller calls back the data received from the lower layer to the upper-layer application;
When data transmission is complete, the mailbox controller notifies the upper layer that the current data has been sent;
The mailbox client releases the channel;
Regarding the Mailbox framework, in the Linux kernel source codedrivers/mailboxThere are related drivers under the directory.
]]>This article introduces the working principle of the IPCC (Inter-Processor Communication Controller) hardware module in the STM32MP157, discusses its process of achieving signal notification between the Cortex-A7 and Cortex-M4 cores through shared memory and hardware interrupt mechanisms, and summarizes the channel allocation, software framework application, and related register configuration of the IPCC.Rpmsg Char Driverhttps://even629.com/en/posts/202606290/2026-06-29T14:00:13.000Z2026-06-29T14:00:13.000Z Timeline
Timeline
2026-06-29
init
This article introduces the implementation mechanism of the Rpmsg Char Driver character device driver based on Linux 5.10.x. It discusses in detail the classic architecture design where the control device and endpoint device are separated, and summarizes the specific processes and key code logic of driver registration, delayed endpoint creation, lock and wait queue synchronization mechanisms, as well as user-space message sending and receiving.
Current code analysis is based on Linux 5.10.x
rpmsg.drawio
rpmsg_char.cimplementsrpmsg_driverand registers it on the Rpmsg Bus, implementing an interface for user-space interaction, undertakingvirtio_rpmsg_bus.cto registerrpmsg_device
rpmsg_char.cis a character device driver with the following hierarchy:
rpmsg_char.drawio
Note that it usespostcore_initcall, which is earlier thanmodule_initearlier, because rpmsg_core.c’s bus also usespostcore_initcall, both are registered after the driver model is ready.
rpmsg_char_initdoes three things:
alloc_chrdev_region(&rpmsg_major, 0, RPMSG_DEV_MAX, "rpmsg") —— Dynamically allocate a major device number,RPMSG_DEV_MAX = MINORMASK+1(i.e., the entire minor device number space).
One per channel; users “create endpoints” on it via ioctl
Endpoint device
/dev/rpmsg0
rpmsg_eptdev
rpmsg_ctrldev_ioctl(CREATE)
One per endpoint; users read/write/poll it to send and receive messages
This separation of “control device + data device” is a classic pattern in Linux:The control node is used to instantiate the data node, and the data node carries the actual I/O。
struct rpmsg_ctrldev
1 2 3 4 5 6 7 8 9 10 11
/** * struct rpmsg_ctrldev - control device for instantiating endpoint devices * @rpdev:underlaying rpmsg device * @cdev:cdev for the ctrl device * @dev:device for the ctrl device */ structrpmsg_ctrldev { structrpmsg_device *rpdev;// Underlying rpmsg channel device structcdevcdev;// Character device structdevicedev;// Embedded device, attached under rpmsg_class };
/** * struct rpmsg_eptdev - endpoint device context * @dev:endpoint device * @cdev:cdev for the endpoint device * @rpdev:underlaying rpmsg device * @chinfo:info used to open the endpoint * @ept_lock:synchronization of @ept modifications * @ept:rpmsg endpoint reference, when open * @queue_lock:synchronization of @queue operations * @queue:incoming message queue * @readq:wait object for incoming queue */ structrpmsg_eptdev { structdevicedev; structcdevcdev;
structrpmsg_device *rpdev;// Underlying channel structrpmsg_channel_infochinfo;// Channel information (name/src/dst) used when opening
structmutexept_lock;// Protect modifications to the ept pointer structrpmsg_endpoint *ept;// Real endpoint created only when opened, can be NULL
spinlock_t queue_lock; // Protect the receive queue structsk_buff_headqueue;// Receive message queue (one skb per message) wait_queue_head_t readq; // Wait queue for blocking reads };
Lock and wait queue:
struct mutex ept_lock;: Protects the ept pointer. The ept becomes NULL in three cases:release、destroy ioctl, parent deviceremove. The read/write path must first acquire this lock to confirm the ept is still alive.
spinlock_t queue_lock;: Protects the queue (skb linked list). The callbackrpmsg_ept_cbenqueues in interrupt/atomic context, while read_iter dequeues in process context, so a spinlock is used here, and in the callbackspin_lock, in readspin_lock_irqsave。
wait_queue_head_t readq;：rpmsg_ept_cbafter enqueuingwake_up_interruptible，read_iterwhen the queue is emptywait_event_interruptible. This is a typical “producer-consumer + wait queue” pattern.
twiceida_simple_get: fromrpmsg_minor_idaget the minor device number, fromrpmsg_ctrl_idaget the id (used forrpmsg_ctrl%d）。
cdev_device_add— register cdev and device together,/dev/rpmsg_ctrlNappears.
Key point:dev->release = rpmsg_ctrldev_release_deviceis assigned aftercdev_device_add. The comment says “We can now rely on the release function for cleanup” — meaningcdev_device_addIf it fails before success, it goes through the manual error label to release; after success, it is handed over to the device model’s release callback for cleanup (kfree when the last reference reaches zero). This is a very standard refcount + release pattern in the Linux device model.
dev_set_drvdata(&rpdev->dev, ctrldev)— so that during remove, ctrldev can be retrieved from rpdev.
rpmsg_chrdev_remove()
1 2 3 4 5 6 7 8 9 10 11 12 13
staticvoidrpmsg_chrdev_remove(struct rpmsg_device *rpdev) { structrpmsg_ctrldev *ctrldev = dev_get_drvdata(&rpdev->dev); int ret;
/* Destroy all endpoints */ ret = device_for_each_child(&ctrldev->dev, NULL, rpmsg_eptdev_destroy); if (ret) dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret);
device_initialize + setclass/parent/groups/drvdata。groups = rpmsg_eptdev_groupsProvide name/src/dst read-only attributes to sysfs
cdev_init withrpmsg_eptdev_fops。
Two ida_simple_get to obtain minor and ept id,dev_set_name(dev, "rpmsg%d", ret) → /dev/rpmsgN。
cdev_device_add, after success set dev->release.
Note: at this pointeptdev->ept == NULL! The actual endpoint has not been created yet.The endpoint is created only at open. This is lazy creation to avoid occupying addresses without use.
The goto order in the error handling path is strictly opposite to the resource acquisition order, following the standard unwind style. Note free_put in eptdev_After device, then kfree—there is actually a detail here:device_initializeAfter that, should use put_device lets the release callback free it, but because release is set in cdev_device_only after add succeeds, and it hasn’t been set in this path, so put_device won’t actually kfree, manual kfree is needed. This is exactly the cost of delayed assignment of release.
#ifdef CONFIG_COMPAT /** * compat_ptr_ioctl - generic implementation of .compat_ioctl file operation * * This is not normally called as a function, but instead set in struct * file_operations as * * .compat_ioctl = compat_ptr_ioctl, * * On most architectures, the compat_ptr_ioctl() just passes all arguments * to the corresponding ->ioctl handler. The exception is arch/s390, where * compat_ptr() clears the top bit of a 32-bit pointer value, so user space * pointers to the second 2GB alias the first 2GB, as is the case for * native 32-bit s390 user space. * * The compat_ptr_ioctl() function must therefore be used only with ioctl * functions that either ignore the argument or pass a pointer to a * compatible data type. * * If any ioctl command handled by fops->unlocked_ioctl passes a plain * integer instead of a pointer, or any of the passed data types * is incompatible between 32-bit and 64-bit architectures, a proper * handler is required instead of compat_ptr_ioctl. */ longcompat_ptr_ioctl(struct file *file, unsignedint cmd, unsignedlong arg) { if (!file->f_op->unlocked_ioctl) return -ENOIOCTLCMD;
ept = rpmsg_create_ept(rpdev, rpmsg_ept_cb, eptdev, eptdev->chinfo); if (!ept) { dev_err(dev, "failed to open %s\n", eptdev->chinfo.name); put_device(dev); return -EINVAL; }
eptdev->ept = ept; filp->private_data = eptdev;
return0; }
rpmsg_create_eptforwarded to core and then to the virtio backend’svirtio_rpmsg_create_ept → __rpmsg_create_ept（virtio_rpmsg_bus.c:). The latter allocates a local address in idr (ifchinfo.src == RPMSG_ADDR_ANYthen dynamically allocate from 1024), bind the callbackrpmsg_ept_cbandpriv=eptdevto that address.
After callback registration, messages sent remotely with dst equal to this local address will triggerrpmsg_ept_cb (see backendrpmsg_recv_singlepressmsg->dstlook up idr and callept->cb）。
get_device/ open failedput_device: ensures the device is not released while the file is open.
/* wake up any blocking processes, waiting for new data */ wake_up_interruptible(&eptdev->readq);
return0; }
The backend calls ept->cb in the virtqueue callback (softirq context), so mutex and sleep cannot be used here; use GFP_ATOMIC and spinlock.
A memory copy (buf → skb) is performed here. The backend obtains the vring buffer with zero-copy during reception, but to pass the data to user space and prevent the buffer from being held by the user for a long time (the backend must return the buffer to rvq as soon as possible), a copy is made into skb.rpmsg_recv_singleImmediately after calling cb,virtqueue_add_inbufreturn the original buffer.
/* Close the endpoint, if it's not already destroyed by the parent */ mutex_lock(&eptdev->ept_lock); if (eptdev->ept) { rpmsg_destroy_ept(eptdev->ept); eptdev->ept = NULL; } mutex_unlock(&eptdev->ept_lock);
/* Discard all SKBs */ skb_queue_purge(&eptdev->queue);
/* Wait for data in the queue */ if (skb_queue_empty(&eptdev->queue)) { spin_unlock_irqrestore(&eptdev->queue_lock, flags);
if (filp->f_flags & O_NONBLOCK) return -EAGAIN;
/* Wait until we get data or the endpoint goes away */ if (wait_event_interruptible(eptdev->readq, !skb_queue_empty(&eptdev->queue) || !eptdev->ept)) return -ERESTARTSYS;
/* We lost the endpoint while waiting */ if (!eptdev->ept) return -EPIPE;
spin_lock_irqsave(&eptdev->queue_lock, flags); }
skb = skb_dequeue(&eptdev->queue); spin_unlock_irqrestore(&eptdev->queue_lock, flags); if (!skb) return -EFAULT;
use = min_t(size_t, iov_iter_count(to), skb->len); if (copy_to_iter(skb->data, use, to) != use) use = -EFAULT;
kfree_skb(skb);
return use; }
The wait condition also checks!ept: this wayWhen destroy sets ept to NULL and calls wake_up, the blocked read can immediately wake up and return -EPIPE, without being stuck forever. This is the standard way to use “resource disappearance” as a wake-up condition.
One read retrieves one message: rpmsg is a protocol with clear message boundaries,one skb = one rpmsg message。use = min_t(size_t, iov_iter_count(to), skb->len);meaning if the user buffer is smaller than the message, the excess is discarded (skb is directly freed). This is a pitfall for beginners: the buffer must be large enough (the backend buffer is 512 bytes minus a 16-byte header = 496 bytes payload).
Usespin_lock_irqsaveinstead ofspin_lock: because reading may occur in a normal process context, but the lock may be held by a callback in interrupt context; disabling interrupts is safer.
kbuf = kzalloc(len, GFP_KERNEL); if (!kbuf) return -ENOMEM;
if (!copy_from_iter_full(kbuf, len, from)) { ret = -EFAULT; goto free_kbuf; }
if (mutex_lock_interruptible(&eptdev->ept_lock)) { ret = -ERESTARTSYS; goto free_kbuf; }
if (!eptdev->ept) { ret = -EPIPE; goto unlock_eptdev; }
if (filp->f_flags & O_NONBLOCK) ret = rpmsg_trysend(eptdev->ept, kbuf, len); else ret = rpmsg_send(eptdev->ept, kbuf, len);
unlock_eptdev: mutex_unlock(&eptdev->ept_lock);
free_kbuf: kfree(kbuf); return ret < 0 ? ret : len; }
Firstcopy_from_iterthen acquire the lock, becauseuser-space copy may cause a page fault and sleep, which should not be done while holding ept_lock—otherwise it would block the destroy path for a long time.
rpmsg_sendThe blocking version goes all the way to the backendrpmsg_send_offchannel_raw(..., wait=true): if no TX buffer, thenwait_event_interruptible_timeout(..., 15000)。rpmsg_trysendiswait=false, if no buffer, immediately-ENOMEM。
On success, returns len (number of bytes written), not ret (backend ret is 0). Note that a single message is limited by the backend buffer:len > buf_size - sizeof(hdr)That is, 496 bytes will-EMSGSIZE。
Sending is also one write = one message, without streaming concatenation.
rpmsg_poll forwarded to the backend’sops->poll— but note the virtio backend’svirtio_endpoint_opsdoes not implement poll, sorpmsg_pollinif (!ept->ops->poll) return 0, that is, under this backend, poll only reports readable, not writable. This is an optional backend implementation.
]]>This article introduces the implementation mechanism of the Rpmsg Char Driver character device driver based on Linux 5.10.x. It discusses in detail the classic architecture design where the control device and endpoint device are separated, and summarizes the specific processes and key code logic of driver registration, delayed endpoint creation, lock and wait queue synchronization mechanisms, as well as user-space message sending and receiving.Rpmsg Corehttps://even629.com/en/posts/202606270/2026-06-27T07:17:13.000Z2026-06-27T07:17:13.000Z Timeline
Timeline
2026-06-27
init
This article introduces the bus abstraction mechanism of Rpmsg Core in Linux 5.10.23 and the access method of its backend, and discusses in detail the matching and scoring rules between devices and drivers as well as the device probing process. It summarizes core logic such as power domain association, automatic endpoint creation, and dynamic address allocation during probing, revealing the implementation details of the rpmsg framework in hardware power management and endpoint communication.
linux 5.10.23
rpmsg.drawio
rpmsg is a bus abstraction that is not tied to any specific transport. Virtio is the most common implementation in Linux currently, but theoretically there can be:
A direct mapping implementation based on shared memory
An implementation based on mailbox interrupts
An implementation based on PCIe doorbell
Each backend only needs to provide its ownrpmsg_endpoint_opsandrpmsg_device_ops, to connect to the rpmsg core. Moreover, not all backends need to support all send variants. For example:
The simplest backend only needs to implement send and trysend.
If the backend does not support explicitly specifying src/dst (offchannel), it can
If the backend does not support poll, user-space write operations are still available (blocking/non-blocking modes are guaranteed by therpmsg_send/rpmsg_trysendsemantics).
if (rpdev->driver_override) return !strcmp(rpdev->driver_override, drv->name);
if (ids) for (i = 0; ids[i].name[0]; i++) if (rpmsg_id_match(rpdev, &ids[i])) return1;
return of_driver_match_device(dev, drv); }
ifrpdev->driver_overridethen only need to comparerpdev->driver_overrideanddrv->name, i.e., specify therpdevforce match a driver with a corresponding name
ifrpdev->id_talbeexists
fromstruct rpmsg_driver *rpdrvextractconst struct rpmsg_device_id *idsthen, traverse the ids table, throughids[i].namematchrpmsg_device, if match succeeds, return 1,
pass__of_device_is_compatiblecalculate the score, find the one with the highest scoreconst struct of_device_id *best_match, and__of_device_is_compatibleis defined as follows:
/** * __of_device_is_compatible() - Check if the node matches given constraints * @device: pointer to node * @compat: required compatible string, NULL or "" for any match * @type: required device_type value, NULL or "" for any match * @name: required node name, NULL or "" for any match * * Checks if the given @compat, @type and @name strings match the * properties of the given @device. A constraints can be skipped by * passing NULL or an empty string as the constraint. * * Returns 0 for no match, and a positive integer on match. The return * value is a relative score with larger values indicating better * matches. The score is weighted for the most specific compatible value * to get the highest score. Matching type is next, followed by matching * name. Practically speaking, this results in the following priority * order for matches: * * 1. specific compatible && type && name * 2. specific compatible && type * 3. specific compatible && name * 4. specific compatible * 5. general compatible && type && name * 6. general compatible && type * 7. general compatible && name * 8. general compatible * 9. type && name * 10. type * 11. name */ staticint __of_device_is_compatible(conststruct device_node *device, constchar *compat, constchar *type, constchar *name) { structproperty *prop; constchar *cp; int index = 0, score = 0;
/* Compatible match has highest priority */ if (compat && compat[0]) { prop = __of_find_property(device, "compatible", NULL); for (cp = of_prop_next_string(prop, NULL); cp; cp = of_prop_next_string(prop, cp), index++) { if (of_compat_cmp(cp, compat, strlen(compat)) == 0) { score = INT_MAX/2 - (index << 2); break; } } if (!score) return0; }
/* Matching type is better than matching name */ if (type && type[0]) { if (!__of_node_is_type(device, type)) return0; score += 2; }
/* Matching name is a bit better than not */ if (name && name[0]) { if (!of_node_name_eq(device, name)) return0; score++; }
/* * when an rpmsg driver is probed with a channel, we seamlessly create * it an endpoint, binding its rx callback to a unique local rpmsg * address. * * if we need to, we also announce about this channel to the remote * processor (needed in case the driver is exposing an rpmsg service). */ staticintrpmsg_dev_probe(struct device *dev) { structrpmsg_device *rpdev = to_rpmsg_device(dev); structrpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver); structrpmsg_channel_infochinfo = {}; structrpmsg_endpoint *ept =NULL; int err;
err = dev_pm_domain_attach(dev, true); if (err) goto out;
if (ept && rpdev->ops->announce_create) { err = rpdev->ops->announce_create(rpdev); if (err) { dev_err(dev, "failed to announce creation\n"); goto remove_rpdev; } }
return0;
remove_rpdev: if (rpdrv->remove) rpdrv->remove(rpdev); destroy_ept: if (ept) rpmsg_destroy_ept(ept); out: return err; }
power domain association
1 2 3
err = dev_pm_domain_attach(dev, true); if (err) goto out;
Purpose: associate the device with a Power Management Domain (genpd).
In modern SoCs, different peripherals may belong to different power domains and can be independently switched on/off
dev_pm_domain_attach(dev, true) the true in it means: if the device tree specifies the device’spower-domainsproperty, the kernel will attempt to automatically attach
if attach fails (e.g., power domain does not exist), subsequent initialization is meaningless, exit directly
Placed first because subsequent endpoint creation and driver initialization may depend on the hardware power being already on. If the power domain is not ready, these operations may fail or even cause hardware anomalies.
ept = rpmsg_create_ept(rpdev, rpdrv->callback, NULL, chinfo); if (!ept) { dev_err(dev, "failed to create endpoint\n"); err = -ENOMEM; goto out; }
rpdev->ept = ept; rpdev->src = ept->addr; }
First determineif (rpdrv->callback)
Simple driver: only needs one receive callback, provide callback during registration, framework automatically creates endpoint for it
Complex driver: may require multiple endpoints, dynamic address management, the callback of such drivers may be NULL, they manually call in their own proberpmsg_create_ept(),
then constructstruct rpmsg_channel_info chipinfo
1 2 3
strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE); // Service name chinfo.src = rpdev->src; // Local address chinfo.dst = RPMSG_ADDR_ANY; // Destination address any
Notedst = RPMSG_ADDR_ANYMeaning: when creating endpoint, it does not bind a fixed peer address, can accept messages from any remote address.
Callrpmsg_create_ept()The parameters passed arestruct rpmsg_device *rpdev，rpdrv->callback，priv = NULL，struct rpmsg_channel_info chinfo, after creating ept, key assignment:rpdev->src = ept->addr, this is a very critical operation!
If before creationrpdev->src = RPMSG_ADDR_ANY, the backend will dynamically allocate an available address
ept->addris the actual local address after backend allocation
Writeept->addrback torpdev->src, ensuring the device structure records the real address
This means: the driver’s receive callback will be bound to this newly allocated address, and messages sent from the remote end to this address will trigger the callback.
if (ept && rpdev->ops->announce_create) { err = rpdev->ops->announce_create(rpdev); if (err) { dev_err(dev, "failed to announce creation\n"); goto remove_rpdev; } }
Ifstruct rpmsg_device *rpdev’sconst struct rpmsg_device_ops *ops;'sannounce_createis set, then call theannounce_create, i.e., called after ept is createdannounce_createthis callback
if (rpdev->ops->announce_destroy) err = rpdev->ops->announce_destroy(rpdev);
if (rpdrv->remove) rpdrv->remove(rpdev);
dev_pm_domain_detach(dev, true);
if (rpdev->ept) rpmsg_destroy_ept(rpdev->ept);
return err; }
The remove function and probe function are in reverse order; first,announce_destroy, then callstruct rpmsg_driver *rpdrvthe remove function in, then calldev_pm_domain_detachdetach the power domain, and finally callrpmsg_destroy_eptdestroyrpdev->ept
This function is the callback when an RPMSG bus device generates a uevent (user space event/hotplug event). It serves as the bridge between the kernel device model and user-space udev. Function location and call chain:
1 2 3 4 5 6 7 8
设备注册到 rpmsg_bus │ ▼ device_add() └── bus_add_device() / bus_probe_device() └── kobject_uevent(KOBJ_ADD) // Trigger uevent └── dev_uevent() // Device's uevent callback └── rpmsg_uevent() // ← This is where (via bus_type.uevent)
The uevent carries a set of environment variables to user space, and udev decides based on these variables:
Create device node
Automatically load driver module
Execute rule script
Line-by-line code analysis
First priority: Device tree format modalias
1 2 3
ret = of_device_uevent_modalias(dev, env); if (ret != -ENODEV) return ret;
If the device is associated with a device tree node (dev->of_node),of_device_uevent_modaliasit will:
Read the compatible property of the device tree
Generate the standard OF modalias format:of:N<name>T<type>C<compatible>
Add to the uevent environment variable
Return value meaning:
0: Successfully added OF modalias, return directly
-ENODEV: Device has no device tree node, continue with RPMSG’s own logic
This will re-invoke rpmsg_uevent(), and udev will process it again. View module alias
1 2 3
$ grep rpmsg /lib/modules/$(uname -r)/modules.alias alias rpmsg:* rpmsg_core alias rpmsg:rpmsg-tty rpmsg_tty
rpmsg_dev_groups
dev_groups is the struct bus in the Linux device model_A field of type, its function is: automatically create a set of sysfs attribute files for each device registered on this bus.
/** * rpmsg_device - device that belong to the rpmsg bus * @dev: the device struct * @id: device id (used to match between rpmsg drivers and devices) * @driver_override: driver name to force a match; do not set directly, * because core frees it; use driver_set_override() to * set or clear it. * @src: local address * @dst: destination address * @ept: the rpmsg endpoint of this channel * @announce: if set, rpmsg will announce the creation/removal of this channel */ structrpmsg_device { structdevicedev;// Base class of the Linux device model structrpmsg_device_idid;// Device identifier (for matching) constchar *driver_override; // Force binding of a specific driver u32 src; // Local address u32 dst; // Destination address structrpmsg_endpoint *ept;// Endpoint (receive callback bound here) bool announce; // Whether to announce lifecycle to the remote side conststructrpmsg_device_ops *ops;// Backend operation table };
struct device dev
This is the embedded base class of the Linux device model.rpmsg_deviceAccess the kernel device model through composition rather than inheritance.
Local address. When the device is created, it may beRPMSG_ADDR_ANY, updated to the actual value after backend allocation
rpmsg_dev_probe()inrpdev->src = ept->addr
dst
Peer address. Usually a known remote service address, orRPMSG_ADDR_ANY
Set by the backend at creation time
src is the address I listen/receive on, dst is who I send to. rpmsg_device represents a logical channel, so it contains both end addresses.
struct rpmsg_endpoint *ept
Points to the default endpoint of this channel. When the driver provides a callback,rpmsg_dev_probe() an endpoint is automatically created and assigned here.
Note: An rpmsg_device can only have one default ept, but the driver can manually create additional endpoints in probe() (e.g., when multiple listening addresses are needed).
bool announce
Controls whether to send to the remote end when the channel is created/destroyed**Name Service (NS)**announcement message.announce = true: sends “I’m online” on creation, “I’m offline” on destruction. The remote processor can update its service table or trigger corresponding client connections upon receipt.
const struct rpmsg_device_ops *ops
Backend operation table, defined inrpmsg_internal.h：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
/** * struct rpmsg_device_ops - indirection table for the rpmsg_device operations * @create_ept:create backend-specific endpoint, required * @announce_create:announce presence of new channel, optional * @announce_destroy:announce destruction of channel, optional * * Indirection table for the operations that a rpmsg backend should implement. * @announce_create and @announce_destroy are optional as the backend might * advertise new channels implicitly by creating the endpoints. */ structrpmsg_device_ops { structrpmsg_endpoint *(*create_ept)(structrpmsg_device *rpdev, rpmsg_rx_cb_tcb, void *priv, structrpmsg_channel_infochinfo);
int (*announce_create)(struct rpmsg_device *ept); int (*announce_destroy)(struct rpmsg_device *ept); };
This is the boundary between the RPMSG core layer and the specific backend:
rpmsg_core.conly calls these interfaces
virtio_rpmsg_bus.c(or other backends) implement these interfaces
Allows the RPMSG framework to support multiple underlying transports (though currently mainly virtio)
/** * struct rpmsg_endpoint - binds a local rpmsg address to its user * @rpdev: rpmsg channel device * @refcount: when this drops to zero, the ept is deallocated * @cb: rx callback handler * @cb_lock: must be taken before accessing/changing @cb * @addr: local rpmsg address * @priv: private data for the driver's use * * In essence, an rpmsg endpoint represents a listener on the rpmsg bus, as * it binds an rpmsg address with an rx callback handler. * * Simple rpmsg drivers shouldn't use this struct directly, because * things just work: every rpmsg driver provides an rx callback upon * registering to the bus, and that callback is then bound to its rpmsg * address when the driver is probed. When relevant inbound messages arrive * (i.e. messages which their dst address equals to the src address of * the rpmsg channel), the driver's handler is invoked to process it. * * More complicated drivers though, that do need to allocate additional rpmsg * addresses, and bind them to different rx callbacks, must explicitly * create additional endpoints by themselves (see rpmsg_create_ept()). */ structrpmsg_endpoint { structrpmsg_device *rpdev; structkrefrefcount; rpmsg_rx_cb_t cb; structmutexcb_lock; u32 addr; void *priv;
conststructrpmsg_endpoint_ops *ops; };
endpoint is a first-class object for sending/receiving
rpmsg core attaches all communication operations torpmsg_endpointinstead ofrpmsg_device. This means:
Arpmsg_device(channel) can have multiple endpoints.
Different endpoints can have different callbacks and addresses.
Send operations are performed through endpoints, naturally carrying the source address.
This is similar to the design of TCP sockets: the device is like a socket fd, and the endpoint is like a specific connection endpoint.
The frameworkrpmsg_dev_probe()automatically creates an endpoint when , calling the backend-implementedrpdev->ops->create_ept()to bind this callback (virtio_rpmsg_bus.c）。
/** * struct rpmsg_driver - rpmsg driver struct * @drv: underlying device driver * @id_table: rpmsg ids serviced by this driver * @probe: invoked when a matching rpmsg channel (i.e. device) is found * @remove: invoked when the rpmsg channel is removed * @callback: invoked when an inbound message is received on the channel */ structrpmsg_driver { structdevice_driverdrv; conststructrpmsg_device_id *id_table; int (*probe)(struct rpmsg_device *dev); void (*remove)(struct rpmsg_device *dev); int (*callback)(struct rpmsg_device *, void *, int, void *, u32); };
struct rpmsg_driverIt is the core structure that driver developers need to fill in the RPMSG framework. It follows the Linux standard device driver model while encapsulating the RPMSG-specific message sending and receiving semantics.
struct device_driver drv
Linux device model base class, used to attach torpmsg_bus
const struct rpmsg_device_id *id_table
Device ID table supported by the driver (matched by service name)
int (*probe)(struct rpmsg_device *)
Called on successful match, executes driver initialization, refer torpmsg_dev_probefunction
void (*remove)(struct rpmsg_device *dev);
Called on device removal/driver unload, performs cleanup
int (*callback)(struct rpmsg_device *, void *, int, void *, u32);
Message reception callback (triggers automatic default endpoint creation by the framework),callbackandprobedivision of labor
/** * struct rpmsg_device_ops - indirection table for the rpmsg_device operations * @create_ept:create backend-specific endpoint, required * @announce_create:announce presence of new channel, optional * @announce_destroy:announce destruction of channel, optional * * Indirection table for the operations that a rpmsg backend should implement. * @announce_create and @announce_destroy are optional as the backend might * advertise new channels implicitly by creating the endpoints. */ structrpmsg_device_ops { structrpmsg_endpoint *(*create_ept)(structrpmsg_device *rpdev, rpmsg_rx_cb_tcb, void *priv, structrpmsg_channel_infochinfo);
int (*announce_create)(struct rpmsg_device *ept); int (*announce_destroy)(struct rpmsg_device *ept); };
Call timing
Member
Required
Call function
Call timing
Precondition
create_ept
Required
rpmsg_create_ept()
① Framework automatically creates default endpoints; ② Driver manually creates endpoints
rpdev->opsNon-empty
announce_create
Optional
rpmsg_dev_probe()
Driverprobe()After success
ept created successfully andops->announce_createnon-empty
announce_destroy
optional
rpmsg_dev_remove()
At the very beginning of device removal/driver unload
// rpmsg_core.c: rpmsg_dev_probe() err = rpdrv->probe(rpdev); // ← ① First let the driver complete initialization if (err) goto destroy_ept;
if (ept && rpdev->ops->announce_create) { // ← ② Announce after driver is ready err = rpdev->ops->announce_create(rpdev); if (err) goto remove_rpdev; }
Backend:
Send a “channel creation” message to the remote processor via the RPMSG Name Service protocol
The message content usually includes: service namerpdev->id.name, local addressrpdev->src
if (rpdev->ops->announce_destroy) // ← ① First executed: notify the remote end err = rpdev->ops->announce_destroy(rpdev); if (rpdrv->remove) // ← ② Then call driver cleanup rpdrv->remove(rpdev); dev_pm_domain_detach(dev, true); // ← ③ Power separation if (rpdev->ept) rpmsg_destroy_ept(rpdev->ept); // ← ④ Finally destroy the endpoint return err;
}
Backend:
Send a “channel destruction” message to the remote end via the name service protocol
After receiving it, the remote end will delete the channel from its own service table; subsequent messages sent to that address will be discarded or return an error
Summary
Operation
Caller
Callee
Core semantics
create_ept
rpmsg_create_ept()
Backend
Allocate resources: bind backend buffer and interrupt to local address
announce_create
rpmsg_dev_probe()
Backend
Publish service: notify remote that “this address has a service listening”
announce_destroy
rpmsg_dev_remove()
Backend
Revoke service: notify remote that “the service at this address is about to stop”
These three hooks together implement the complete lifecycle management of RPMSG “create-publish-revoke”, serving as the most critical contract interface between the core layer and the backend
/** * struct rpmsg_endpoint_ops - indirection table for rpmsg_endpoint operations * @destroy_ept:see @rpmsg_destroy_ept(), required * @send:see @rpmsg_send(), required * @sendto:see @rpmsg_sendto(), optional * @send_offchannel:see @rpmsg_send_offchannel(), optional * @trysend:see @rpmsg_trysend(), required * @trysendto:see @rpmsg_trysendto(), optional * @trysend_offchannel:see @rpmsg_trysend_offchannel(), optional * @poll:see @rpmsg_poll(), optional * * Indirection table for the operations that a rpmsg backend should implement. * In addition to @destroy_ept, the backend must at least implement @send and * @trysend, while the variants sending data off-channel are optional. */ structrpmsg_endpoint_ops { void (*destroy_ept)(struct rpmsg_endpoint *ept);
int (*send)(struct rpmsg_endpoint *ept, void *data, int len); int (*sendto)(struct rpmsg_endpoint *ept, void *data, int len, u32 dst); int (*send_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len);
int (*trysend)(struct rpmsg_endpoint *ept, void *data, int len); int (*trysendto)(struct rpmsg_endpoint *ept, void *data, int len, u32 dst); int (*trysend_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len); __poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp, poll_table *wait); };
Decoupling of rpmsg core and backend
The architecture of the rpmsg subsystem can be viewed as two layers:
This layering allows the core to perform name service announcement during device registration (via rpmsg_device_ops.announce_create), while the actual data transmission goes through the endpoint (via rpmsg_endpoint_ops.send）。
drivers/rpmsg/rpmsg_core.cEach API in it is a thin layer of encapsulation, taking a few typical functions as examples:
1 2 3 4 5 6 7 8 9 10
intrpmsg_send(struct rpmsg_endpoint *ept, void *data, int len) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->send) return -ENXIO;
return ept->ops->send(ept, data, len);
}
Because send is required, the core has no fallback. If XIO.
1 2 3 4 5 6 7 8
intrpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->sendto) return -ENXIO; return ept->ops->sendto(ept, data, len, dst); }
Seerpmsg_core.cAlthough the comment says sendto is optional, the semantics of optional are “the backend can choose not to support this operation,” not “the core will handle compatibility for you.” If a backend only implements send and trysend, calling sendto will fail.
1 2 3 4 5 6 7 8 9
__poll_trpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp, poll_table *wait) { if (WARN_ON(!ept)) return0; if (!ept->ops->poll) return0;
return ept->ops->poll(ept, filp, wait); }
virtio_rpmsg_bus.cdoes not implement poll, so throughrpmsg_poll()returns 0 when called. Anddrivers/rpmsg/rpmsg_char.c
1
mask |= rpmsg_poll(eptdev->ept, filp, wait);
rpmsg_char.cprovides user-space/dev/rpmsgXinterface.rpmsg_poll()The result is ORed intopoll maskIf the backend does not implement poll, user-space operations on/dev/rpmsgXdoingpoll()can only detect read events (EPOLLIN), and cannot throughrpmsg_poll()Check the write-ready status. However, due to virtio’srpmsg_sendseries either blocking or returning immediately, the write path does not actually rely on poll.
Summary
ops
required
Core behavior (when not implemented)
virtio backend
destroy_ept
✅ required
N/A (will not be NULL, must be set during initialization)
/** * rpmsg_create_ept() - create a new rpmsg_endpoint * @rpdev: rpmsg channel device * @cb: rx callback handler * @priv: private data for the driver's use * @chinfo: channel_info with the local rpmsg address to bind with @cb * * Every rpmsg address in the system is bound to an rx callback (so when * inbound messages arrive, they are dispatched by the rpmsg bus using the * appropriate callback handler) by means of an rpmsg_endpoint struct. * * This function allows drivers to create such an endpoint, and by that, * bind a callback, and possibly some private data too, to an rpmsg address * (either one that is known in advance, or one that will be dynamically * assigned for them). * * Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint * is already created for them when they are probed by the rpmsg bus * (using the rx callback provided when they registered to the rpmsg bus). * * So things should just work for simple drivers: they already have an * endpoint, their rx callback is bound to their rpmsg address, and when * relevant inbound messages arrive (i.e. messages which their dst address * equals to the src address of their rpmsg channel), the driver's handler * is invoked to process it. * * That said, more complicated drivers might need to allocate * additional rpmsg addresses, and bind them to different rx callbacks. * To accomplish that, those drivers need to call this function. * * Drivers should provide their @rpdev channel (so the new endpoint would belong * to the same remote processor their channel belongs to), an rx callback * function, an optional private data (which is provided back when the * rx callback is invoked), and an address they want to bind with the * callback. If @addr is RPMSG_ADDR_ANY, then rpmsg_create_ept will * dynamically assign them an available rpmsg address (drivers should have * a very good reason why not to always use RPMSG_ADDR_ANY here). * * Returns a pointer to the endpoint on success, or NULL on error. */ struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev, rpmsg_rx_cb_t cb, void *priv, struct rpmsg_channel_info chinfo) { if (WARN_ON(!rpdev)) returnNULL;
/** * rpmsg_destroy_ept() - destroy an existing rpmsg endpoint * @ept: endpoing to destroy * * Should be used by drivers to destroy an rpmsg endpoint previously * created with rpmsg_create_ept(). As with other types of "free" NULL * is a valid parameter. */ voidrpmsg_destroy_ept(struct rpmsg_endpoint *ept) { if (ept && ept->ops) ept->ops->destroy_ept(ept); } EXPORT_SYMBOL(rpmsg_destroy_ept);
/** * rpmsg_send() - send a message across to the remote processor * @ept: the rpmsg endpoint * @data: payload of message * @len: length of payload * * This function sends @data of length @len on the @ept endpoint. * The message will be sent to the remote processor which the @ept * endpoint belongs to, using @ept's address and its associated rpmsg * device destination addresses. * In case there are no TX buffers available, the function will block until * one becomes available, or a timeout of 15 seconds elapses. When the latter * happens, -ERESTARTSYS is returned. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_send(struct rpmsg_endpoint *ept, void *data, int len) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->send) return -ENXIO;
/** * rpmsg_sendto() - send a message across to the remote processor, specify dst * @ept: the rpmsg endpoint * @data: payload of message * @len: length of payload * @dst: destination address * * This function sends @data of length @len to the remote @dst address. * The message will be sent to the remote processor which the @ept * endpoint belongs to, using @ept's address as source. * In case there are no TX buffers available, the function will block until * one becomes available, or a timeout of 15 seconds elapses. When the latter * happens, -ERESTARTSYS is returned. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->sendto) return -ENXIO;
/** * rpmsg_send_offchannel() - send a message using explicit src/dst addresses * @ept: the rpmsg endpoint * @src: source address * @dst: destination address * @data: payload of message * @len: length of payload * * This function sends @data of length @len to the remote @dst address, * and uses @src as the source address. * The message will be sent to the remote processor which the @ept * endpoint belongs to. * In case there are no TX buffers available, the function will block until * one becomes available, or a timeout of 15 seconds elapses. When the latter * happens, -ERESTARTSYS is returned. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_send_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->send_offchannel) return -ENXIO;
/** * rpmsg_trysend() - send a message across to the remote processor * @ept: the rpmsg endpoint * @data: payload of message * @len: length of payload * * This function sends @data of length @len on the @ept endpoint. * The message will be sent to the remote processor which the @ept * endpoint belongs to, using @ept's address as source and its associated * rpdev's address as destination. * In case there are no TX buffers available, the function will immediately * return -ENOMEM without waiting until one becomes available. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_trysend(struct rpmsg_endpoint *ept, void *data, int len) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->trysend) return -ENXIO;
/** * rpmsg_trysendto() - send a message across to the remote processor, specify dst * @ept: the rpmsg endpoint * @data: payload of message * @len: length of payload * @dst: destination address * * This function sends @data of length @len to the remote @dst address. * The message will be sent to the remote processor which the @ept * endpoint belongs to, using @ept's address as source. * In case there are no TX buffers available, the function will immediately * return -ENOMEM without waiting until one becomes available. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_trysendto(struct rpmsg_endpoint *ept, void *data, int len, u32 dst) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->trysendto) return -ENXIO;
/** * rpmsg_poll() - poll the endpoint's send buffers * @ept:the rpmsg endpoint * @filp:file for poll_wait() * @wait:poll_table for poll_wait() * * Returns mask representing the current state of the endpoint's send buffers */ __poll_trpmsg_poll(struct rpmsg_endpoint *ept, struct file *filp, poll_table *wait) { if (WARN_ON(!ept)) return0; if (!ept->ops->poll) return0;
/** * rpmsg_trysend_offchannel() - send a message using explicit src/dst addresses * @ept: the rpmsg endpoint * @src: source address * @dst: destination address * @data: payload of message * @len: length of payload * * This function sends @data of length @len to the remote @dst address, * and uses @src as the source address. * The message will be sent to the remote processor which the @ept * endpoint belongs to. * In case there are no TX buffers available, the function will immediately * return -ENOMEM without waiting until one becomes available. * * Can only be called from process context (for now). * * Returns 0 on success and an appropriate error value on failure. */ intrpmsg_trysend_offchannel(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len) { if (WARN_ON(!ept)) return -EINVAL; if (!ept->ops->trysend_offchannel) return -ENXIO;
/* * match a rpmsg channel with a channel info struct. * this is used to make sure we're not creating rpmsg devices for channels * that already exist. */ staticintrpmsg_device_match(struct device *dev, void *data) { structrpmsg_channel_info *chinfo = data; structrpmsg_device *rpdev = to_rpmsg_device(dev);
if (chinfo->src != RPMSG_ADDR_ANY && chinfo->src != rpdev->src) return0;
if (chinfo->dst != RPMSG_ADDR_ANY && chinfo->dst != rpdev->dst) return0;
if (strncmp(chinfo->name, rpdev->id.name, RPMSG_NAME_SIZE)) return0;
]]>This article introduces the bus abstraction mechanism of Rpmsg Core in Linux 5.10.23 and the access method of its backend, and discusses in detail the matching and scoring rules between devices and drivers as well as the device probing process. It summarizes core logic such as power domain association, automatic endpoint creation, and dynamic address allocation during probing, revealing the implementation details of the rpmsg framework in hardware power management and endpoint communication.Virtio Rpmsg Bushttps://even629.com/en/posts/202606230/2026-06-22T14:17:13.000Z2026-06-22T14:17:13.000Z Timeline
Timeline
2026-06-22
init
This article introduces the implementation principles and core data structures of the virtio-based rpmsg bus driver in the Linux kernel. It discusses the basic communication model of rpmsg and provides a detailed analysis of the rpmsg_device、rpmsg_endpoint creation and destruction logic, as well as the underlying transport mechanisms such as virtqueue send/receive channels, buffer management, DMA mapping, and concurrency control within the virtproc_info private state.
virtio_rpmsg_bus.cis the Linux kernel’svirtio-based rpmsg bus driver. Its role is:
Enable the Linux main core and remote processor to send and receive rpmsg messages via the virtio vring mechanism, and abstract the remote service into a Linuxrpmsg_device, for upper-layer rpmsg driver binding and use. This file itself is thevirtio transport implementation of the rpmsg bus, it does not care about specific business protocols, such as audio, sensors, TEE, MCU control, etc.; it is only responsible for delivering messages to the corresponding endpoint.
Basic Communication Model
rpmsg
The communication unit of rpmsg is:
rpmsg_devicerpmsg channel device, a communication channel, is a “device”
rpmsg_driverThe driver that handles the business of this channel
rpmsg_endpointThe actual sending and receiving endpoints on the channel (address + callback)
Relationship among the three:
1 2 3 4 5
rpmsg_driver ←—— 匹配 ——→ rpmsg_device | | 持有 v rpmsg_endpoint
rpmsg_device is the middle “device managed by the driver”. When creatingrpmsg_device, the probe function is triggered for matching, and upon successful matching, therpmsg_driver->probefunction is called
/** * rpmsg_device - device that belong to the rpmsg bus * @dev: the device struct * @id: device id (used to match between rpmsg drivers and devices) * @driver_override: driver name to force a match; do not set directly, * because core frees it; use driver_set_override() to * set or clear it. * @src: local address * @dst: destination address * @ept: the rpmsg endpoint of this channel * @announce: if set, rpmsg will announce the creation/removal of this channel */ structrpmsg_device { structdevicedev; structrpmsg_device_idid; constchar *driver_override; u32 src; u32 dst; structrpmsg_endpoint *ept; bool announce;
/** * struct rpmsg_device_ops - indirection table for the rpmsg_device operations * @create_ept:create backend-specific endpoint, required * @announce_create:announce presence of new channel, optional * @announce_destroy:announce destruction of channel, optional * * Indirection table for the operations that a rpmsg backend should implement. * @announce_create and @announce_destroy are optional as the backend might * advertise new channels implicitly by creating the endpoints. */ structrpmsg_device_ops { structrpmsg_endpoint *(*create_ept)(structrpmsg_device *rpdev, rpmsg_rx_cb_tcb, void *priv, structrpmsg_channel_infochinfo);
int (*announce_create)(struct rpmsg_device *ept); int (*announce_destroy)(struct rpmsg_device *ept); };
An rpmsg_device is equivalent to a logical channel, for example:
channel name: “rpmsg-demo”
src: local endpoint address
dst: remote endpoint address
Invirtio_rpmsg_bus.c, the channel is created like this (rpmsg_create_channel()）：
That is: the remote announces a service “rpmsg-demo”, Linux creates arpmsg_devicerepresenting this channel, or the local side actively creates a service “rpmsg-demo”, i.e., creates arpmsg_devicerepresenting the local channel. After announcement, the NS service on the remote side also creates a channel for “rpmsg-demo”. The local and remoterpmsg_devicehave src and dst exactly opposite, and communicate through this channel.
In fact,virtio_rpmsg_bus.cthe abstract rpmsg channel descriptor in is
1 2 3 4 5 6 7 8 9 10 11 12 13
/** * struct virtio_rpmsg_channel - rpmsg channel descriptor * @rpdev: the rpmsg channel device * @vrp: the virtio remote processor device this channel belongs to * * This structure stores the channel that links the rpmsg device to the virtio * remote processor device. */ structvirtio_rpmsg_channel { structrpmsg_devicerpdev;
structvirtproc_info *vrp; };
i.e., arpmsg_deviceAlso add the core data structurestruct virtproc_info *vrp, which is the key data structure for virtio to implement the rpmsg bus
struct rpmsg_endpoint
rpmsg_deviceJust like a telephone line + an extension number service, whilerpmsg_endpointrepresents the person actually answering the phone
/** * struct rpmsg_endpoint - binds a local rpmsg address to its user * @rpdev: rpmsg channel device * @refcount: when this drops to zero, the ept is deallocated * @cb: rx callback handler * @cb_lock: must be taken before accessing/changing @cb * @addr: local rpmsg address * @priv: private data for the driver's use * * In essence, an rpmsg endpoint represents a listener on the rpmsg bus, as * it binds an rpmsg address with an rx callback handler. * * Simple rpmsg drivers shouldn't use this struct directly, because * things just work: every rpmsg driver provides an rx callback upon * registering to the bus, and that callback is then bound to its rpmsg * address when the driver is probed. When relevant inbound messages arrive * (i.e. messages which their dst address equals to the src address of * the rpmsg channel), the driver's handler is invoked to process it. * * More complicated drivers though, that do need to allocate additional rpmsg * addresses, and bind them to different rx callbacks, must explicitly * create additional endpoints by themselves (see rpmsg_create_ept()). */ structrpmsg_endpoint { structrpmsg_device *rpdev; structkrefrefcount; rpmsg_rx_cb_t cb; structmutexcb_lock; u32 addr; void *priv;
conststructrpmsg_endpoint_ops *ops; };
The logic related to rpmsg_endpoint is mainly inrpmsg_core.c, among which the most important arerpmsg_rx_cb_t cbandconst struct rpmsg_endpoint_ops *opsthese two members:
/** * struct rpmsg_endpoint_ops - indirection table for rpmsg_endpoint operations * @destroy_ept:see @rpmsg_destroy_ept(), required * @send:see @rpmsg_send(), required * @sendto:see @rpmsg_sendto(), optional * @send_offchannel:see @rpmsg_send_offchannel(), optional * @trysend:see @rpmsg_trysend(), required * @trysendto:see @rpmsg_trysendto(), optional * @trysend_offchannel:see @rpmsg_trysend_offchannel(), optional * @poll:see @rpmsg_poll(), optional * * Indirection table for the operations that a rpmsg backend should implement. * In addition to @destroy_ept, the backend must at least implement @send and * @trysend, while the variants sending data off-channel are optional. */ structrpmsg_endpoint_ops { void (*destroy_ept)(struct rpmsg_endpoint *ept);
int (*send)(struct rpmsg_endpoint *ept, void *data, int len); int (*sendto)(struct rpmsg_endpoint *ept, void *data, int len, u32 dst); int (*send_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len);
int (*trysend)(struct rpmsg_endpoint *ept, void *data, int len); int (*trysendto)(struct rpmsg_endpoint *ept, void *data, int len, u32 dst); int (*trysend_offchannel)(struct rpmsg_endpoint *ept, u32 src, u32 dst, void *data, int len); __poll_t (*poll)(struct rpmsg_endpoint *ept, struct file *filp, poll_table *wait); };
represents the operation function of rpmsg_endpoint.
Endpoint creation
The core function is:__rpmsg_create_ept(), which is the operation function of rpmsg_device
/* do we need to allocate a local address ? */ if (addr == RPMSG_ADDR_ANY) { id_min = RPMSG_RESERVED_ADDRESSES; id_max = 0; } else { id_min = addr; id_max = addr + 1; }
mutex_lock(&vrp->endpoints_lock);
/* bind the endpoint to an rpmsg address (and allocate one if needed) */ id = idr_alloc(&vrp->endpoints, ept, id_min, id_max, GFP_KERNEL); if (id < 0) { dev_err(dev, "idr_alloc failed: %d\n", id); goto free_ept; } ept->addr = id;
/** * __rpmsg_destroy_ept() - destroy an existing rpmsg endpoint * @vrp: virtproc which owns this ept * @ept: endpoing to destroy * * An internal function which destroy an ept without assuming it is * bound to an rpmsg channel. This is needed for handling the internal * name service endpoint, which isn't bound to an rpmsg channel. * See also __rpmsg_create_ept(). */ staticvoid __rpmsg_destroy_ept(struct virtproc_info *vrp, struct rpmsg_endpoint *ept) { /* make sure new inbound messages can't find this ept anymore */ mutex_lock(&vrp->endpoints_lock); idr_remove(&vrp->endpoints, ept->addr); mutex_unlock(&vrp->endpoints_lock);
Purpose: points to the underlying virtio device. It is the root of this rpmsg instance. Through it, you can obtain: - vdev->dev device node (dev_err/dev_for debugging) - vdev->config virtio configuration operations (reset/del_vqs, etc.) - vdev->priv points back to vrp itself Set in probe:
1 2 3
vrp->vdev = vdev; ... vdev->priv = vrp;
In callback, it relies on this to retrieve vrp:
1
structvirtproc_info *vrp = rvq->vdev->priv;
struct virtqueue *rvq, *svq
Purpose:
rvq = receive virtqueue: remote -> Linux
svq = send virtqueue: Linux -> remote These are the two channels for receiving and sending. In probe:
Used in many places asnum_bufs / 2as a boundary, for exampleget_a_tx_buf()：
1
if (vrp->last_sbuf < vrp->num_bufs / 2)
unsigned int buf_size
Purpose: byte size of a single buffer, currently fixed at 512 (MAX_RPMSG_BUF_SIZE）。
In the probe function
1
vrp->buf_size = MAX_RPMSG_BUF_SIZE;
It determines:
address stride of each buffer:sbufs + buf_size * i
upper limit of a single message payload
1 2
if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) return -EMSGSIZE;
int last_sbuf
Function: The “pioneer cursor” of TX buffer, recording how many have been initially allocated in order. Inget_a_tx_buf()used in:
1 2 3 4
if (vrp->last_sbuf < vrp->num_bufs / 2) ret = vrp->sbufs + vrp->buf_size * vrp->last_sbuf++; else ret = virtqueue_get_buf(vrp->svq, &len);
last_sbuf < num_bufs/2: If there are unused new TX buffers, take them in order
Otherwise: All TX buffers have been used, switch to recycling from the used ring Once the upper limit is reached,last_sbufit stops growing and relies entirely onvirtqueue_get_buf()recycling.
dma_addr_t bufs_dma
Function: The DMA base address of the entire buffer (address from device/DMA perspective). In probe, it isdma_alloc_coherent()returned by:
Function: Protects shared state on the sending side: svq, sbufs, sleepers. Allows multiple senders to call concurrentlyrpmsg_send(). A mutex is used because sending may need to wake up a remote processor that is “napping”, and this process may sleep, so a sleepable mutex must be used.
struct idr endpoints
Function: The idr index table for all local endpoints, with the key being the endpoint address. Used to quickly find an endpoint by address. This is the core data structure for message distribution. When creating an endpoint, allocate an address and insert:
1 2
id = idr_alloc(&vrp->endpoints, ept, id_min, id_max, GFP_KERNEL); ept->addr = id;
So rpmsg is actuallyaddress-based dispatch, it relies on this idr.
struct mutex endpoints_lock
Purpose: Protect concurrent access to the endpoints idr. Must hold when adding, deleting, querying, or modifying endpoints:
1 2 3 4 5
mutex_lock(&vrp->endpoints_lock); ept = idr_find(&vrp->endpoints, ...); if (ept) kref_get(&ept->refcount); /* After finding, first add a reference to prevent release */ mutex_unlock(&vrp->endpoints_lock);
Note that it and tx_lock are two different locks: - tx_lockProtects the send path - endpoints_lockProtects the endpoint table
wait_queue_head_t sendq
Purpose: Senders waiting for a TX buffer sleep on this wait queue. When there is no TX buffer, rpmsg_send() sleeps and waits:
Purpose: How many senders are currently waiting for a TX buffer (waiter count). It works with the dynamic toggling of the TX complete interrupt:
1 2 3 4 5 6 7
/* First waiter: Enable tx-complete callback */ if (atomic_inc_return(&vrp->sleepers) == 1) virtqueue_enable_cb(vrp->svq);
/* Last waiter: Disable tx-complete callback */ if (atomic_dec_and_test(&vrp->sleepers)) virtqueue_disable_cb(vrp->svq);
Design purpose:
No one waiting for TX buffer: Disable tx-complete interrupt to save overhead
Someone waiting for TX buffer: Enable tx-complete interrupt, wake up immediately after remote returns buffer
(This is the design of version 5.10. The Linux 7.1.1 version has removed sleepers due to the introduction of poll support.)
struct rpmsg_endpoint *ns_ept
Purpose: dedicated endpoint for name service (fixed address 53). It does not belong to any ordinary rpmsg channel; it is used internally by the bus to handle remote service ‘create/destroy’ notifications. It is created in probe when the remote side supports the NS feature:
/* super simple buffer "allocator" that is just enough for now */ staticvoid *get_a_tx_buf(struct virtproc_info *vrp) { unsignedint len; void *ret;
/* support multiple concurrent senders */ mutex_lock(&vrp->tx_lock);
4/* * either pick the next unused tx buffer * (half of our buffers are used for sending messages) */ if (vrp->last_sbuf < vrp->num_bufs / 2) ret = vrp->sbufs + vrp->buf_size * vrp->last_sbuf++; /* or recycle a used one */ else ret = virtqueue_get_buf(vrp->svq, &len);
mutex_unlock(&vrp->tx_lock);
return ret; }
This function is a very simple TX buffer allocator.
It has two phases:
1 2 3 4 5
阶段 1：还有从未使用过的 TX buffer 按数组顺序从 vrp->sbufs 里拿
阶段 2：所有 TX buffer 都至少用过一次 从 svq used ring 回收远端已经读完的 TX buffer
vrp->vdev = vdev; // Initialize members of struct virtproc_info idr_init(&vrp->endpoints); mutex_init(&vrp->endpoints_lock); mutex_init(&vrp->tx_lock); init_waitqueue_head(&vrp->sendq);
/* We expect two virtqueues, rx and tx (and in this order) */ err = virtio_find_vqs(vdev, 2, vqs, vq_cbs, names, NULL); if (err) goto free_vrp;
vrp->rvq = vqs[0]; vrp->svq = vqs[1];
/* we expect symmetric tx/rx vrings */ WARN_ON(virtqueue_get_vring_size(vrp->rvq) != virtqueue_get_vring_size(vrp->svq));
/* we need less buffers if vrings are small */ if (virtqueue_get_vring_size(vrp->rvq) < MAX_RPMSG_NUM_BUFS / 2) vrp->num_bufs = virtqueue_get_vring_size(vrp->rvq) * 2; else vrp->num_bufs = MAX_RPMSG_NUM_BUFS;
vrp->buf_size = MAX_RPMSG_BUF_SIZE;
total_buf_space = vrp->num_bufs * vrp->buf_size;
/* allocate coherent memory for the buffers */ bufs_va = dma_alloc_coherent(vdev->dev.parent, total_buf_space, &vrp->bufs_dma, GFP_KERNEL); if (!bufs_va) { err = -ENOMEM; goto vqs_del; }
dev_dbg(&vdev->dev, "buffers: va %pK, dma %pad\n", bufs_va, &vrp->bufs_dma);
/* half of the buffers is dedicated for RX */ vrp->rbufs = bufs_va;
/* and half is dedicated for TX */ vrp->sbufs = bufs_va + total_buf_space / 2;
/* set up the receive buffers */ for (i = 0; i < vrp->num_bufs / 2; i++) { structscatterlistsg; void *cpu_addr = vrp->rbufs + i * vrp->buf_size;
/* if supported by the remote processor, enable the name service */ if (virtio_has_feature(vdev, VIRTIO_RPMSG_F_NS)) { /* a dedicated endpoint handles the name service msgs */ vrp->ns_ept = __rpmsg_create_ept(vrp, NULL, rpmsg_ns_cb, vrp, RPMSG_NS_ADDR); if (!vrp->ns_ept) { dev_err(&vdev->dev, "failed to create the ns ept\n"); err = -ENOMEM; goto free_coherent; } }
/* * Prepare to kick but don't notify yet - we can't do this before * device is ready. */ notify = virtqueue_kick_prepare(vrp->rvq);
/* From this point on, we can notify and get callbacks. */ virtio_device_ready(vdev);
/* tell the remote processor it can start sending messages */ /* * this might be concurrent with callbacks, but we are only * doing notify, not a full kick here, so that's ok. */ if (notify) virtqueue_notify(vrp->rvq);
Linux first places a batch of empty RX buffers into the available ring, so that the remote processor can later write messages into these buffers.
Disable TX complete interrupt by default
1
virtqueue_disable_cb(vrp->svq);
Because most of the time, the sender does not need to receive an interrupt every time a TX buffer is consumed by the remote end. Only when Linux has no TX buffers and the sender needs to sleep and wait, is the TX complete interrupt temporarily enabled.
Create name service endpoint
If the remote end supports:
1
VIRTIO_RPMSG_F_NS
Then create a name service endpoint with address53:
/** * rpmsg_send_offchannel_raw() - send a message across to the remote processor * @rpdev: the rpmsg channel * @src: source address * @dst: destination address * @data: payload of message * @len: length of payload * @wait: indicates whether caller should block in case no TX buffers available * * This function is the base implementation for all of the rpmsg sending API. * * It will send @data of length @len to @dst, and say it's from @src. The * message will be sent to the remote processor which the @rpdev channel * belongs to. * * The message is sent using one of the TX buffers that are available for * communication with this remote processor. * * If @wait is true, the caller will be blocked until either a TX buffer is * available, or 15 seconds elapses (we don't want callers to * sleep indefinitely due to misbehaving remote processors), and in that * case -ERESTARTSYS is returned. The number '15' itself was picked * arbitrarily; there's little point in asking drivers to provide a timeout * value themselves. * * Otherwise, if @wait is false, and there are no TX buffers available, * the function will immediately fail, and -ENOMEM will be returned. * * Normally drivers shouldn't use this function directly; instead, drivers * should use the appropriate rpmsg_{try}send{to, _offchannel} API * (see include/linux/rpmsg.h). * * Returns 0 on success and an appropriate error value on failure. */ staticintrpmsg_send_offchannel_raw(struct rpmsg_device *rpdev, u32 src, u32 dst, void *data, int len, bool wait) { structvirtio_rpmsg_channel *vch = to_virtio_rpmsg_channel(rpdev); structvirtproc_info *vrp = vch->vrp; structdevice *dev = &rpdev->dev; structscatterlistsg; structrpmsg_hdr *msg; int err;
/* * We currently use fixed-sized buffers, and therefore the payload * length is limited. * * One of the possible improvements here is either to support * user-provided buffers (and then we can also support zero-copy * messaging), or to improve the buffer allocator, to support * variable-length buffer sizes. */ if (len > vrp->buf_size - sizeof(struct rpmsg_hdr)) { dev_err(dev, "message is too big (%d)\n", len); return -EMSGSIZE; }
/* grab a buffer */ msg = get_a_tx_buf(vrp); if (!msg && !wait) return -ENOMEM;
/* no free buffer ? wait for one (but bail after 15 seconds) */ while (!msg) { /* enable "tx-complete" interrupts, if not already enabled */ rpmsg_upref_sleepers(vrp);
/* * sleep until a free buffer is available or 15 secs elapse. * the timeout period is not configurable because there's * little point in asking drivers to specify that. * if later this happens to be required, it'd be easy to add. */ err = wait_event_interruptible_timeout(vrp->sendq, (msg = get_a_tx_buf(vrp)), msecs_to_jiffies(15000));
/* disable "tx-complete" interrupts if we're the last sleeper */ rpmsg_downref_sleepers(vrp);
/* timeout ? */ if (!err) { dev_err(dev, "timeout waiting for a tx buffer\n"); return -ERESTARTSYS; } }
/* add message to the remote processor's virtqueue */ err = virtqueue_add_outbuf(vrp->svq, &sg, 1, msg, GFP_KERNEL); if (err) { /* * need to reclaim the buffer here, otherwise it's lost * (memory won't leak, but rpmsg won't use it again for TX). * this will wait for a buffer management overhaul. */ dev_err(dev, "virtqueue_add_outbuf failed: %d\n", err); goto out; }
/* tell the remote processor it has a pending message to read */ virtqueue_kick(vrp->svq); out: mutex_unlock(&vrp->tx_lock); return err; }
Full meaning: Linux fills the TX buffer → adds the buffer to the output virtqueue → kicks the remote processor → the remote side takes the message from the virtqueue
That is, the TX callback function isrpmsg_xmit_done
Note: Normally, the TX complete interrupt is disabled; it is only enabled when a sender is sleeping and waiting for a buffer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
/* * This is invoked whenever the remote processor completed processing * a TX msg we just sent it, and the buffer is put back to the used ring. * * Normally, though, we suppress this "tx complete" interrupt in order to * avoid the incurred overhead. */ staticvoidrpmsg_xmit_done(struct virtqueue *svq) { structvirtproc_info *vrp = svq->vdev->priv;
dev_dbg(&svq->vdev->dev, "%s\n", __func__);
/* wake up potential senders that are waiting for a tx buffer */ wake_up_interruptible(&vrp->sendq); }
When the remote end consumes the TX buffer, the virtio backend places the buffer into the used ring and triggers the TX complete callback. Linux wakes up the sending thread waiting for the TX buffer.
/* are we the first sleeping context waiting for tx buffers ? */ if (atomic_inc_return(&vrp->sleepers) == 1) /* enable "tx-complete" interrupts before dozing off */ virtqueue_enable_cb(vrp->svq);
mutex_unlock(&vrp->tx_lock); }
Meaning: Before a sending thread prepares to sleep due to lack of TX buffer:sleepers++, if this is the first waiter, enable the TX complete callback Correspondingly, there is alsorpmsg_downref_sleepers(): After the sending thread wakes up:sleepers--, if this is the last waiter, disable the TX complete callback
Purpose of this mechanism:
No one waiting for TX buffer: disable TX complete interrupt to reduce overhead
Someone waiting for TX buffer: enable TX complete interrupt to immediately wake up the waiter when the remote end returns the buffer
/* called when an rx buffer is used, and it's time to digest a message */ staticvoidrpmsg_recv_done(struct virtqueue *rvq) { structvirtproc_info *vrp = rvq->vdev->priv; structdevice *dev = &rvq->vdev->dev; structrpmsg_hdr *msg; unsignedint len, msgs_received = 0; int err;
msg = virtqueue_get_buf(rvq, &len); if (!msg) { dev_err(dev, "uhm, incoming signal, but no used buffer ?\n"); return; }
while (msg) { err = rpmsg_recv_single(vrp, dev, msg, len); if (err) break;
/* let's make sure no one deallocates ept while we use it */ if (ept) kref_get(&ept->refcount);
mutex_unlock(&vrp->endpoints_lock);
if (ept) { /* make sure ept->cb doesn't go away while we use it */ mutex_lock(&ept->cb_lock);
if (ept->cb) ept->cb(ept->rpdev, msg->data, msg_len, ept->priv, virtio32_to_cpu(vrp->vdev, msg->src));
mutex_unlock(&ept->cb_lock);
/* farewell, ept, we don't need you anymore */ kref_put(&ept->refcount, __ept_release); } else dev_warn(dev, "msg received with no recipient\n");
/* publish the real size of the buffer */ rpmsg_sg_init(&sg, msg, vrp->buf_size);
/* add the buffer back to the remote processor's virtqueue */ err = virtqueue_add_inbuf(vrp->rvq, &sg, 1, msg, GFP_KERNEL); if (err < 0) { dev_err(dev, "failed to add a virtqueue buffer: %d\n", err); return err; }
return0; }
When receiving, it is not distributed by channel name, but by:msg->dst, invrp->endpointslook up the local endpoint. So rpmsg actually runs more like address-based messaging, and the channel name is mainly used for device discovery and driver matching. Main steps:
Finally, inrpmsg_recv_done()If a message has been processed inside, kick the remote end:
1 2
if (msgs_received) virtqueue_kick(vrp->rvq);
Name service mechanism
Note: name service is an optional feature. Feature definition:
1
#define VIRTIO_RPMSG_F_NS0
If the remote end does not support this feature, dynamic service discovery is unavailable. In this case, the channel may need to be created statically.
rpmsg supports the remote end dynamically notifying Linux: I created a service or I destroyed a service, this is called name service. Related structure:
Note hererpdevThe parameter isNULL, because the NS endpoint does not belong to a regular rpmsg channel, but is an internal endpoint used by the bus itself.
/* * the name service ept does _not_ belong to a real rpmsg channel, * and is handled by the rpmsg bus itself. * for sanity reasons, make sure a valid rpdev has _not_ sneaked * in somehow. */ if (rpdev) { dev_err(dev, "anomaly: ns ept has an rpdev handle\n"); return -EINVAL; }
/* don't trust the remote processor for null terminating the name */ msg->name[RPMSG_NAME_SIZE - 1] = '\0';
When a local rpmsg channel that needs to be announced is created, the driver constructsrpmsg_ns_msg, and sends it to the remote NS address53(atrpmsg_core.c). Create notification:
/* * create an rpmsg channel using its name and address info. * this function will be used to create both static and dynamic * channels. */ staticstruct rpmsg_device *rpmsg_create_channel(struct virtproc_info *vrp, struct rpmsg_channel_info *chinfo) { structvirtio_rpmsg_channel *vch; structrpmsg_device *rpdev; structdevice *tmp, *dev = &vrp->vdev->dev; int ret;
/* make sure a similar channel doesn't already exist */ tmp = rpmsg_find_device(dev, chinfo); if (tmp) { /* decrement the matched device's refcount back */ put_device(tmp); dev_err(dev, "channel %s:%x:%x already exist\n", chinfo->name, chinfo->src, chinfo->dst); returnNULL; }
vch = kzalloc(sizeof(*vch), GFP_KERNEL); if (!vch) returnNULL;
/* Link the channel to our vrp */ vch->vrp = vrp;
/* Assign public information to the rpmsg_device */ rpdev = &vch->rpdev; rpdev->src = chinfo->src; rpdev->dst = chinfo->dst; rpdev->ops = &virtio_rpmsg_ops;
/* * rpmsg server channels has predefined local address (for now), * and their existence needs to be announced remotely */ rpdev->announce = rpdev->src != RPMSG_ADDR_ANY;
远端发送 NS 消息到 addr 53 | v rpmsg_recv_done() | v rpmsg_recv_single() | v endpoint 53 的 callback | v rpmsg_ns_cb() | | RPMSG_NS_CREATE v rpmsg_create_channel() | v rpmsg_register_device() | v 匹配上层 rpmsg driver
RX buffer lifecycle
RX buffer lifecycle:
1 2 3 4 5 6 7 8 9 10 11
probe 时 add_inbuf ↓ 远端写入消息 ↓ Linux virtqueue_get_buf ↓ 调用 callback ↓ Linux 重新 add_inbuf ↓ 远端再次使用
Therefore, the RX buffer is cyclically reused.
TX buffer lifecycle
TX buffer lifecycle:
1 2 3 4 5 6 7 8 9 10 11 12 13
Linux 从 sbufs 初始池拿 buffer ↓ 填消息 ↓ virtqueue_add_outbuf ↓ 远端消费 ↓ buffer 进入 used ring ↓ Linux virtqueue_get_buf 回收 ↓ 再次发送
]]>This article introduces the implementation principles and core data structures of the virtio-based rpmsg bus driver in the Linux kernel. It discusses the basic communication model of rpmsg and provides a detailed analysis of the rpmsg_device、rpmsg_endpoint creation and destruction logic, as well as the underlying transport mechanisms such as virtqueue send/receive channels, buffer management, DMA mapping, and concurrency control within the virtproc_info private state.Commonly Used Data Structures in the Linux Kernelhttps://even629.com/en/posts/202605243/2026-05-24T15:08:13.000Z2026-05-25T15:08:13.000Z Timeline
Timeline
2026-05-24
init
This article introduces the core data structures with high practical usage frequency in the Linux 6.x kernel, detailing the definitions, core APIs, and typical use cases of structures such as doubly linked circular lists, hash linked lists, red-black trees, radix trees, extensible arrays, and priority linked lists.
Overview
A large number of general-purpose data structures are defined in the Linux kernel, which run through various subsystems such as process scheduling, memory management, file systems, and device drivers. This article follows theactual usage frequencyfrom high to low to sort out these data structures, covering data structure definitions, core APIs, and typical use cases.
info
This article is based on the Linux 6.x kernel, and some APIs may vary slightly between different versions.
Basic Containers
list_head — Doubly Linked Circular List
Usage frequency: Highest. This is the most widely used data structure in the Linux kernel, bar none. Almost every subsystem uses it.
success
The Linux linked list implementation willSeparation of data and linked list nodes, the linked list node is embedded into the structure, rather than the structure containing a linked list pointer. The essence of this design is: a set of linked list operations applies to all data types.
~ # insmod list_test.ko [ 11.039661] list_test: loading out-of-tree module taints kernel. [ 11.050065] list_test_init is called [ 11.050235] val is 0 [ 11.050289] val is 2 [ 11.050325] val is 4 [ 11.050390] val is 6 [ 11.050429] val is 8 [ 11.050466] val is 10 [ 11.050734] val is 12 [ 11.050808] val is 14 [ 11.050885] val is 16 [ 11.050936] val is 18 ~ # rmmod list_test.ko [ 17.474727] del 0 [ 17.474865] del 2 [ 17.474913] del 4 [ 17.474950] del 6 [ 17.474981] del 8 [ 17.475060] del 10 [ 17.475103] del 12 [ 17.475135] del 14 [ 17.475169] del 16 [ 17.475221] del 18 [ 17.475263] list_test_exit is called
/** * list_add - add a new entry * @new: new entry to be added * @head: list head to add it after * * Insert a new entry after the specified head. * This is good for implementing stacks. */ staticinlinevoidlist_add(struct list_head *new, struct list_head *head) { __list_add(new, head, head->next); }
/** * list_add_tail - add a new entry * @new: new entry to be added * @head: list head to add it before * * Insert a new entry before the specified head. * This is useful for implementing queues. */ staticinlinevoidlist_add_tail(struct list_head *new, struct list_head *head) { __list_add(new, head->prev, head); }
list_add_tailis inserted intohead->prevandheadbetween. But because this is a ring, “in front of head” is logically equivalent to “the end of the list”.
/** * list_del - deletes entry from list. * @entry: the element to delete from the list. * Note: list_empty() on entry does not return true after this, the entry is * in an undefined state. */ staticinlinevoidlist_del(struct list_head *entry) { __list_del_entry(entry); entry->next = LIST_POISON1; entry->prev = LIST_POISON2; }
/** * list_del_init - deletes entry from list and reinitialize it. * @entry: the element to delete from the list. */ staticinlinevoidlist_del_init(struct list_head *entry) { __list_del_entry(entry); INIT_LIST_HEAD(entry); }
/** * list_replace - replace old entry by new one * @old : the element to be replaced * @new : the new element to insert * * If @old was empty, it will be overwritten. */ staticinlinevoidlist_replace(struct list_head *old, struct list_head *new) { new->next = old->next; new->next->prev = new; new->prev = old->prev; new->prev->next = new; }
/** * list_replace_init - replace old entry by new one and initialize the old one * @old : the element to be replaced * @new : the new element to insert * * If @old was empty, it will be overwritten. */ staticinlinevoidlist_replace_init(struct list_head *old, struct list_head *new) { list_replace(old, new); INIT_LIST_HEAD(old); }
hlist — hash linked list
hlist is specifically designed forhash tabledesigned as a variant of a doubly linked list. That is, when hashing the data to be stored, if a collision occurs, it usesthe linked list approachto string together and store the conflicting data. Typically, the usage order of elements in a hash table is: data storage —> data retrieval —> data deletion. Compared with list_head the difference lies in: the head node only uses one struct hlist_head(single pointer), saving memory in the hash table array.
Its core design motivation is to solve the standard doubly circular linked list list_head existing when used as a hash bucketmemory wasteandsemantic mismatchproblems.
Feature
list_head (Standard Linked List)
hlist_head + hlist_node (Hash Linked List)
Head Node Structure
Complete Bidirectional Pointer (next, prev)
Only One Unidirectional Pointer (first)
Data Node Structure
Bidirectional Pointer (next, prev)
Bidirectional Pointer (next, pprev)
Is Circular?
Yes (Head and Tail Connected)
No (Ends with NULL)
Empty List Check
head->next == head
head->first == NULL
Memory Overhead (Head Node)
2 Pointers (16 Bytes/64-bit)
1 pointer (8 bytes/64 bits)
Header file:<linux/list.h>
Data structure:
1 2 3 4 5 6 7
structhlist_head { structhlist_node *first;// Only one pointer! };
structhlist_node { structhlist_node *next, **pprev;// pprev points to the next pointer of the previous node };
pprev Its type is struct hlist_node **(pointer to a pointer). It does not store “the address of the previous node”, but “the memory address of the next field in the previous node”。
For the hlist linked list head -> A -> B
For node B in the middle of the linked list:B->pprev == &(A->next)
For node A of the linked list:A->pprev == &(head->first)
WRITE_ONCE(*pprev, next); if (next) WRITE_ONCE(next->pprev, pprev); }
/** * hlist_del - Delete the specified hlist_node from its list * @n: Node to delete. * * Note that this function leaves the node in hashed state. Use * hlist_del_init() or similar instead to unhash @n. */ staticinlinevoidhlist_del(struct hlist_node *n) { __hlist_del(n); n->next = LIST_POISON1; n->pprev = LIST_POISON2; }
/** * hlist_del_init - Delete the specified hlist_node from its list and initialize * @n: Node to delete. * * Note that this function leaves the node in unhashed state. */ staticinlinevoidhlist_del_init(struct hlist_node *n) { if (!hlist_unhashed(n)) { __hlist_del(n); INIT_HLIST_NODE(n); } }
/** * hlist_add_head - add a new entry at the beginning of the hlist * @n: new entry to be added * @h: hlist head to add it after * * Insert a new entry after the specified head. * This is good for implementing stacks. */ staticinlinevoidhlist_add_head(struct hlist_node *n, struct hlist_head *h) { structhlist_node *first = h->first; WRITE_ONCE(n->next, first); if (first) WRITE_ONCE(first->pprev, &n->next); WRITE_ONCE(h->first, n); WRITE_ONCE(n->pprev, &h->first); }
/** * hlist_add_before - add a new entry before the one specified * @n: new entry to be added * @next: hlist node to add it before, which must be non-NULL */ staticinlinevoidhlist_add_before(struct hlist_node *n, struct hlist_node *next) { WRITE_ONCE(n->pprev, next->pprev); WRITE_ONCE(n->next, next); WRITE_ONCE(next->pprev, &n->next); WRITE_ONCE(*(n->pprev), n); }
/** * hlist_add_behing - add a new entry after the one specified * @n: new entry to be added * @prev: hlist node to add it after, which must be non-NULL */ staticinlinevoidhlist_add_behind(struct hlist_node *n, struct hlist_node *prev) { WRITE_ONCE(n->next, prev->next); WRITE_ONCE(prev->next, n); WRITE_ONCE(n->pprev, &prev->next);
if (n->next) WRITE_ONCE(n->next->pprev, &n->next); }
/** * hlist_add_fake - create a fake hlist consisting of a single headless node * @n: Node to make a fake list out of * * This makes @n appear to be its own predecessor on a headless hlist. * The point of this is to allow things like hlist_del() to work correctly * in cases where there is no list. */ staticinlinevoidhlist_add_fake(struct hlist_node *n) { n->pprev = &n->next; }
/** * hlist_fake: Is this node a fake hlist? * @h: Node to check for being a self-referential fake hlist. */ staticinlineboolhlist_fake(struct hlist_node *h) { return h->pprev == &h->next; }
rbtree — Red-Black Tree
Most used in the kernelSelf-balancing binary search tree, providing O(log n) search, insertion, and deletion. Each node of a red-black tree has a storage bit indicating the node’s color, which can be Red or Black. Properties of a red-black tree:
Each node is either black or red.
The root node is black.
Every leaf node (NIL) is black. [Note: Here, leaf nodes refer to empty (NIL or NULL) leaf nodes!]
If a node is red, then its children must be black.
All paths from a node to its descendant nodes contain the same number of black nodes. This property ensures that no path is more than twice as long as any other, thus, a red-black tree is a relatively balanced binary tree.
All operations on a red-black tree must maintain its properties. Red-black trees are widely used, mainly to store ordered data, with a time complexity of O(log n) and very high efficiency. cfs_rq uses a red-black tree to store tasks.
structrb_node { unsignedlong __rb_parent_color; structrb_node *rb_right; structrb_node *rb_left; } __attribute__((aligned(sizeof(long)))); /* The alignment might seem pointless, but allegedly CRIS needs it */
structrb_root { structrb_node *rb_node; };
At first glance, it seems there is no field defined for color here, but this is where the cleverness of this red-black tree implementation lies.__rb_parent_colorThis field actually contains both color information and a pointer to the parent node. Because this field is of type long and requires alignment of size sizeof(long), on a typical 32-bit machine, the last two bits are always 0, so one of these bits can be used to represent the color.
The key lies in Memory alignment (Alignment)：
struct rb_node forced to align by sizeof(long) alignment.
On a 32-bit system,sizeof(long) == 4, meaning any valid rb_node pointer address must be a multiple of 4, i.e., the lowest binary 2 bits are always 00。
On a 64-bit system,sizeof(long) == 8, the lowest 3 bits are always 000。
In fact, the least significant bit is used here to represent color information. The following operations on the parent pointer and color information are essentially operations onrb_parent_color’s bits.
/* 'empty' nodes are nodes that are known not to be inserted in an rbtree */ #define RB_EMPTY_NODE(node) \ ((node)->__rb_parent_color == (unsigned long)(node)) #define RB_CLEAR_NODE(node) \ ((node)->__rb_parent_color = (unsigned long)(node))
Linux’s red-black tree implementation is optimized for speed, so it has one less level of indirection than traditional implementations (with better cache locality). Each struct rb_node instance of the structure is embedded in the data structure it manages, so there is no need to rely on pointers to separate rb_node from the data structure it manages.
Users should write their own tree search and insertion functions to call the provided red-black tree functions, rather than using a comparison callback function pointer.
Locking code is also left to the user of the red-black tree to write。
// SPDX-License-Identifier: GPL-2.0 /* * rbtree_demo.c - Linux 5.10.x Red-Black Tree Module Demo * Demonstration: Insert、Search、Delete、In-order traversal、Reverse-order traversal、Get first and last nodes */ #include<linux/module.h> #include<linux/kernel.h> #include<linux/init.h> #include<linux/rbtree.h> #include<linux/slab.h> #include<linux/random.h>
/* ========== 1. Define a custom structure containing rb_node ========== */ structmy_node { structrb_noderb;/* Must be embedded as a member, usually at the beginning or anywhere */ unsignedlong data; /* Data */ };
/* Global red-black tree root node */ staticstructrb_rootmy_tree = RB_ROOT;
/* ========== 2. Auxiliary macro: Reverse lookup of host structure from rb_node ========== */ #define rb_entry_my(ptr) rb_entry((ptr), struct my_node, rb)
while (node) { structmy_node *entry = rb_entry_my(node);
if (data < entry->data) // Current node is greater than the key to find, go to the left subtree node = node->rb_left; elseif (data > entry->data) // Current node is less than the key to find, go to the right node = node->rb_right; else return entry; /* Found */ } returnNULL; /* Not found */ }
/** * Insert node - O(log n) * Return: true=Newly inserted, false=keyAlready exists(Not inserted) * * 【Key】Linux 5.10.x Use a two-step method: * 1) rb_link_node() : Link the node under the parent node（Do not color） * 2) rb_insert_color(): Fix red-black tree properties（Rotate+Recolor） */ staticboolmy_rb_insert(struct rb_root *root, struct my_node *new_node) { structrb_node **link = &root->rb_node; // Insertion position to be found structrb_node *parent =NULL; unsignedlong data = new_node->data;
/* Step 1: Standard BST search for insertion position */ while (*link) { structmy_node *entry = rb_entry_my(*link); parent = *link;
if (data < entry->data) link = &(*link)->rb_left; elseif (data > entry->data) link = &(*link)->rb_right; else returnfalse; /* Key already exists, do not insert duplicate */ }
/* Step 2: Link and color */ rb_link_node(&new_node->rb, parent, link); rb_insert_color(&new_node->rb, root); returntrue; }
xarray predecessor, used for mapping integer IDs to pointers. Although xarray has gradually replaced it, there is still a large amount of code using radix trees in the kernel.
If it is a new project, please use directly <linux/xarray.h> the XArray API. XArray fixes many design flaws of radix_tree (such as preload complexity, index offset issues), and the API is more concise. radix_tree in 5.10.x is just a compatibility layer on top of XArray.
/** * Safely insert node * 【Critical】must first preload then insert within the lock，avoid triggering sleep allocation while holding the lock, which could cause deadlock or OOM */ staticintsafe_insert(unsignedlong index, struct my_data *data) { int ret;
/* Pre-allocate node memory (sleep allowed) */ ret = radix_tree_preload(GFP_KERNEL); if (ret) return ret;
spin_lock(&my_rtree_lock); ret = radix_tree_insert(&my_rtree, index, data); spin_unlock(&my_rtree_lock);
spin_lock(&my_rtree_lock); data = radix_tree_delete(&my_rtree, index); spin_unlock(&my_rtree_lock);
kfree(data); /* delete returns the removed pointer, the caller is responsible for freeing it */ }
/** * Use Tag Batch marking and retrieval * Fixed：Use struct radix_tree_iter as an iterator */ staticvoiddemo_tag_operations(void) { structmy_data *d; void **slot; structradix_tree_iteriter;/* correct iterator type */
pr_info("rtree_demo: === TAG Operations ===\n");
/* tag index=100 with tag 0 */ spin_lock(&my_rtree_lock); radix_tree_tag_set(&my_rtree, 100, 0); spin_unlock(&my_rtree_lock);
/* batch retrieval by tag */ rcu_read_lock(); radix_tree_for_each_tagged(slot, &my_rtree, &iter, 0, 0) { d = radix_tree_deref_slot(slot); if (unlikely(radix_tree_deref_retry(d))) { slot = radix_tree_iter_retry(&iter); /* retry passing iter */ continue; } if (d) pr_info("rtree_demo: TAGGED index=%lu name=%s\n", iter.index, d->name); /* get index from iter.index */ } rcu_read_unlock(); }
/* RADIX_TREE() macro is statically initialized, no manual INIT required_RADIX_TREE */
/* --- Insertion Test --- */ d = create_data(42, "hello"); ret = safe_insert(42, d); pr_info("rtree_demo: INSERT index=42 ret=%d\n", ret);
d = create_data(100, "world"); ret = safe_insert(100, d); pr_info("rtree_demo: INSERT index=100 ret=%d\n", ret);
/* Test duplicate insertion */ d = create_data(42, "duplicate"); ret = safe_insert(42, d); pr_info("rtree_demo: INSERT DUP index=42 ret=%d (expect -EEXIST)\n", ret); kfree(d); /* Duplicate insertion failed, manual release */
/* --- Search Test --- */ d = safe_lookup(42); pr_info("rtree_demo: LOOKUP 42 => %s\n", d ? d->name : "NULL");
d = safe_lookup(999); pr_info("rtree_demo: LOOKUP 999 => %s\n", d ? d->name : "NULL");
/* --- Tag Test --- */ demo_tag_operations();
/* --- Deletion Test --- */ safe_delete(42); d = safe_lookup(42); pr_info("rtree_demo: AFTER DELETE 42 => %s\n", d ? d->name : "NULL");
return0; }
/* ========== Module Unload: Safely traverse and release all remaining nodes ========== */ staticvoid __exit radix_tree_demo_exit(void) { structmy_data *d; void **slot; structradix_tree_iteriter;/* Correct iterator type */
rcu_read_lock(); radix_tree_for_each_slot(slot, &my_rtree, &iter, 0) { d = radix_tree_deref_slot(slot); if (unlikely(radix_tree_deref_retry(d))) { slot = radix_tree_iter_retry(&iter); /* retry passes iter */ continue; } if (d) { /* Must be deleted within the lock, and use iter.index */ spin_lock(&my_rtree_lock); radix_tree_delete(&my_rtree, iter.index); spin_unlock(&my_rtree_lock); kfree(d); } } rcu_read_unlock();
xarray Introduced in Linux 4.20A new generation radix tree replacement, providing a mapping from integers (unsigned long) to pointers, with a cleaner API and better performance.
plist On list_head added topriority, the head always points to the node with the highest priority (a smaller prio value represents a higher priority), commonly used in scenarios where “the highest priority must always be processed first”.
Header file:<linux/plist.h>
Data structure:
1 2 3 4 5 6 7 8 9
structplist_node { int prio; structlist_headprio_list;// Link to nodes of the same priority structlist_headnode_list;// Overall linked list };
structplist_head { structlist_headnode_list;// All nodes sorted by priority };
Core API:
API
Description
plist_head_init(head)
Initialization
plist_node_init(node, prio)
Initialize node
plist_add(node, head)
Insert by priority
plist_del(node, head)
Delete node
plist_first(head)
Get the node with the highest priority
plist_head_empty(head)
Check if empty
llist — lockless linked list
llist(lock-less list) is alockless singly linked list, implemented based on CAS operations, performs better than spinlock + in specific scenarios (such as interrupts and process shared data) list_head performs better.
Header file:<linux/llist.h>
Data structure:
1 2 3 4 5 6 7
structllist_head { structllist_node *first; };
structllist_node { structllist_node *next; };
Core API:
API
Description
llist_add(new, head)
Insert at head (lock-free)
llist_del_all(head)
Atomically detach the entire linked list
llist_del_first(head)
Delete the first node
llist_empty(head)
Check if empty
Typical pattern:
1 2 3 4 5 6 7 8 9 10 11
// Producer (can be in interrupt context) structllist_node *node = kmalloc(sizeof(*node), GFP_ATOMIC); llist_add(node, &my_llist);
// Consumer (process context) structllist_node *list = llist_del_all(&my_llist); // Atomically take the entire linked list structllist_node *entry, *tmp; llist_for_each_entry_safe(entry, tmp, list) { process(entry); kfree(entry); }
rhashtable — resizable hash table
rhashtable is aautomatically expandable and shrinkablehash table implementation that supports RCU lookup, suitable for hash scenarios requiring dynamic growth.
Header file:<linux/rhashtable.h>
Core API:
API
Description
rhashtable_init(ht, params)
Initialization
rhashtable_insert_slow(ht, key, obj)
Insertion
rhashtable_lookup(ht, key, params)
Lookup
rhashtable_remove(ht, obj, params)
Deletion
rhashtable_free_and_destroy(ht, fn, data)
Destruction
Typical applications in the kernel:
Connection tracking table for network namespaces
XFRM security policy database
Hash type implementation of BPF map
maple_tree — Maple Tree
A new data structure introduced in Linux 6.1 to replace the red-black tree + linked list combination in VMA management.maple_tree is a B-tree variant, supportingrange operations(range operations), which is highly efficient for VMA lookup, traversal, and gap searching.
VMA management: Linux 6.1+ uses maple_tree to replace red-black tree + doubly linked list management vm_area_struct
User-space programs (user-space RCU library URCU also implements maple tree)
interval_tree — Interval tree
Interval tree is an enhanced red-black tree, used to manageintervals([start, last]), supporting fast lookup of all intervals overlapping with a given interval. Based on rbtree_augmented implementation.
Header file:<linux/interval_tree.h>
Data structure:
1 2 3 4 5 6
structinterval_tree_node { structrb_noderb; unsignedlong start; // Interval start unsignedlong last; // Interval end unsignedlong __subtree_last; // Maximum last in subtree (augmented info) };
Core API:
API
Description
interval_tree_insert(node, root)
Insert
interval_tree_remove(node, root)
Delete
interval_tree_iter_first(root, start, last)
Find first overlapping interval
interval_tree_iter_next(node, start, last)
Find next overlapping interval
Typical applications in the kernel:
VMA interval lookup (find virtual memory areas overlapping with a given address range)
GEM buffer management in DRM GPU drivers
klist — kernel object linked list
klist is correct list_head wrapper, and kobject Used in conjunction with the system, providing get/put reference counting protection: automatically acquires a reference to node objects while traversing the list, preventing nodes from being freed during traversal.
Header file:<linux/klist.h>
Data structure:
1 2 3 4 5 6 7 8 9 10 11 12
structklist_node { void *n_klist; // Field no longer used structlist_headn_node; structkrefn_ref;// Reference count };
In the device driver model bus_type 's device list
In the device driver model driver 's device list
ID, Bitmap, and DMA
idr — ID allocator
idr Providesinteger ID to pointermapping, automatically allocating a unique integer ID and associating it to a pointer. Suitable for scenarios where “an integer handle is needed”.
Header file:<linux/idr.h>
Core API (modern interface):
API
Description
idr_alloc(idr, ptr, start, end, gfp)
Allocate ID and associate pointer
idr_find(idr, id)
Find pointer by ID
idr_remove(idr, id)
Delete ID mapping
idr_for_each(idr, fn, data)
Iterate over all entries
idr_destroy(idr)
Destroy idr
idr_init(idr)
Initialize
Usage example:
1 2 3 4 5 6 7 8 9 10 11
DEFINE_IDR(my_idr);
// Allocate int id; id = idr_alloc(&my_idr, ptr, 1, 0, GFP_KERNEL); // Allocate starting from 1
ida is idr A simplified version that only allocates integer IDs without associating pointers (used when only unique integer IDs are needed, with lower memory overhead).
Header file:<linux/idr.h>
Core API:
API
Description
ida_alloc(ida, gfp)
Allocate an ID
ida_free(ida, id)
Release ID
ida_alloc_range(ida, min, max, gfp)
Allocate ID in range
ida_init(ida)
Initialize
ida_destroy(ida)
Destroy
bitmap / cpumask — Bitmap
Kernel use unsigned long Implements bitmaps using arrays, providing an efficient set of bit operations.cpumask A special form of bitmap, specifically describing CPU sets.
Header file:<linux/bitmap.h> / <linux/cpumask.h>
Core API (bitmap):
API
Description
bitmap_zero(dst, nbits)
Clear all
bitmap_set(dst, pos, nbits)
Set bit
bitmap_clear(dst, pos, nbits)
Clear bit
bitmap_find_next_zero_area(buf, len, start, n, mask)
Find contiguous zero region
bitmap_and(dst, src1, src2, nbits)
Bitwise AND
bitmap_or(dst, src1, src2, nbits)
Bitwise OR
Core API (cpumask):
API
Description
cpumask_set_cpu(cpu, mask)
Add CPU to mask
cpumask_clear_cpu(cpu, mask)
Remove CPU from mask
cpumask_test_cpu(cpu, mask)
Test if CPU is in mask
for_each_cpu(cpu, mask)
Iterate over CPUs in mask
cpumask_of(cpu)
Get mask for a single CPU
cpu_possible_mask
All possible CPUs in the system
cpu_online_mask
Currently online CPUs
cpu_present_mask
Currently present CPUs
Typical applications in the kernel:
IRQ affinity settings (specifying which CPUs handle interrupts)
Process’s cpus_allowed(setting which CPUs a process can run on)
DMA mask of memory nodes
scatterlist — scatter-gather list
scatterlist Used to describenon-contiguous memory regions, which is extremely common in DMA (Direct Memory Access) scenarios: linking scattered physical memory fragments into a whole for the DMA engine to process at once.
int nents = dma_map_sg(dev, sg, 2, DMA_TO_DEVICE); // ... initiate DMA transfer ... dma_unmap_sg(dev, sg, 2, DMA_TO_DEVICE);
Typical application in kernel:
Block device I/O (scatter-gather list in bio)
Network drivers (scatter-gather Tx/Rx)
Any data transfer involving DMA
Data buffers for encryption/decryption subsystems
Concurrency and synchronization
atomic_t — atomic variable
Atomic operations in the kernel used for simple counting and flags, the foundation of lock-free programming. On 32-bit platforms atomic_t it is 32-bit, and on 64-bit platforms there is also atomic64_t。
encapsulation refcount_t, providing reference count management for objects, working with release callback to automatically release resources when the count reaches zero.
refcount_t is atomic_t 's enhanced version, providing overflow protection—stops incrementing after reaching the maximum value, avoiding use-after-free vulnerabilities caused by reference count overflow.
Almost all kernel objects that require lifecycle management
spinlock_t — Spinlock
The most fundamental of the Linux kernelspinlock, used for short critical section protection in SMP systems. When the holder is spinning on one CPU, executors on other CPUs are also spinning.
Header file:<linux/spinlock.h>
Data structure (simplified):
1 2 3 4 5 6
typedefstructspinlock { union { structraw_spinlockrlock; // ... }; } spinlock_t;
Core API:
API
Description
spin_lock_init(lock)
Dynamic initialization
DEFINE_SPINLOCK(lock)
Static definition + initialization
spin_lock(lock)
Acquire lock (disable kernel preemption)
spin_unlock(lock)
Release lock
spin_lock_irq(lock)
Acquire lock and disable local interrupts
spin_unlock_irq(lock)
Release lock and enable local interrupts
spin_lock_irqsave(lock, flags)
Acquire lock, save interrupt state
spin_unlock_irqrestore(lock, flags)
Release lock, restore interrupt state
spin_lock_bh(lock)
Acquire lock and disable bottom half
spin_trylock(lock)
Try to acquire lock (non-blocking)
spin_is_locked(lock)
Check lock status
warning
While holding a spinlockMust not sleep(Cannot call kmalloc(GFP_KERNEL)、copy_from_user operations that may block, etc.). This is one of the most common sources of bugs in the kernel.
Selection guide:
Scenario
API
Between process contexts
spin_lock / spin_unlock
Between process and interrupt
spin_lock_irqsave / spin_unlock_irqrestore
Between different interrupts
spin_lock_irqsave / spin_unlock_irqrestore
Between process and bottom half
spin_lock_bh / spin_unlock_bh
mutex — mutual exclusion lock
Unlike spinlocks,mutex Yields the CPU and sleeps when the lock cannot be acquired, suitable forCritical sections that may sleep。
mutex The locker must be responsible for unlocking (lock/unlock in different contexts is not allowed). The kernel strictly checks for this.
Choosing between spinlock and mutex:
spinlock
mutex
When unable to acquire
Spin-wait
Sleep and yield CPU
Critical section
Short (nanosecond level)
Can be longer (millisecond level)
Can it sleep?
Absolutely not
Can
Interrupt context
Available
Not available
System overhead
Low
Higher (involves scheduling)
completion — completion count
completion is implemented in the kernela thread waiting for another thread to complete a tasksynchronization mechanism, which is lighter and has clearer semantics than semaphores.
RCU (Read-Copy-Update) is an importantlock-free synchronization mechanism, suitable for read-mostly scenarios. Readers are completely lock-free, writers copy first and then update, and wait for all readers to finish before reclaiming old data.
A wait queue is a more general waiting mechanism: a process puts itself into the wait queue and goes to sleep, and is woken up when the condition is met.
Header file:<linux/wait.h>
Data structure:
1 2 3 4 5 6 7 8 9 10 11
structwait_queue_head { spinlock_t lock; structlist_headhead;// Linked list of wait entries };
structwait_queue_entry { unsignedint flags; void *private; // Usually points to task_struct wait_queue_func_t func; // Wakeup callback (usually autoremove)_wake_function） structlist_headentry; };
Core API:
API
Description
DECLARE_WAIT_QUEUE_HEAD(wq)
Static definition
init_waitqueue_head(wq)
Dynamic initialization
wait_event(wq, condition)
Wait until condition is true
wait_event_interruptible(wq, condition)
Wait interruptible by signal
wait_event_timeout(wq, condition, timeout)
Wait with timeout
wake_up(wq)
Wake up all waiters
wake_up_interruptible(wq)
Wake up TASK_INTERRUPTIBLE waiters
wake_up_nr(wq, nr)
Wake up nr waiters
Usage example:
1 2 3 4 5 6 7 8 9
DECLARE_WAIT_QUEUE_HEAD(wq); int data_ready = 0;
// Wait side wait_event_interruptible(wq, data_ready != 0);
// Wakeup side data_ready = 1; wake_up_interruptible(&wq);
Typical applications in the kernel:
Process state switching (TASK_INTERRUPTIBLE / TASK_UNINTERRUPTIBLE）
Blocking I/O in device drivers (read/write waiting for data)
Read/write waiting for Pipe, Socket
work_struct / workqueue — Work queue
Work queue willTask deferred to process contextexecution, which is one of the common methods for interrupt bottom half processing.
Header file:<linux/workqueue.h>
Data structure:
1 2 3 4 5 6 7 8
structwork_struct { atomic_long_t data; structlist_headentry; work_func_t func; // Work function };
// Work function signature: typedefvoid(*work_func_t)(struct work_struct *work);
Core API:
API
Description
DECLARE_WORK(work, func)
Static definition
INIT_WORK(work, func)
Dynamic initialization
schedule_work(work)
Schedule to system work queue
schedule_delayed_work(dwork, delay)
Delayed scheduling
queue_work(wq, work)
Schedule to specified work queue
cancel_work_sync(work)
Cancel and wait for completion
flush_work(work)
Wait for work completion
alloc_ordered_workqueue(name, flags)
Create ordered workqueue
Usage example:
1 2 3 4 5 6 7 8 9 10
staticvoidmy_work_handler(struct work_struct *work) { pr_info("工作在进程上下文执行\n"); // Can sleep here! }
DECLARE_WORK(my_work, my_work_handler);
// Trigger (e.g., in interrupt handler) schedule_work(&my_work);
Typical applications in the kernel:
Interrupt bottom-half processing
Deferred initialization of device drivers
Packet processing in the network stack
GPU driver command submission
timer_list — kernel timer
Used after a specified timeexecute a callback function(softirq context), with jiffies-level precision (usually 1ms~10ms). For higher precision, use hrtimer。
hrtimer ProvidesNanosecond-levelprecision timer, managed at the bottom layer based on a red-black tree. It is the foundation of the modern Linux timer subsystem.
kobject is the cornerstone of the Linux device driver model, providing unified reference counting, sysfs representation, and hotplug event support for all kernel objects.
structkset { structlist_headlist;// All kobjects belonging to this kset spinlock_t list_lock; structkobjectkobj;// Itself is also a kobject conststructkset_uevent_ops *uevent_ops; };
struct device、struct driver、struct bus_type base classes of the device model, etc.
uevent Hotplug events (e.g., USB drive insertion notifying udev)
notifier_block — Notifier Chain
The Notifier Chain is in the kernelpublish-subscribepattern implementation: a subsystem publishes events, and other interested modules register callbacks to receive notifications.
Header file:<linux/notifier.h>
Data structure:
1 2 3 4 5
structnotifier_block { notifier_fn_t notifier_call; // Callback function structnotifier_block __rcu *next;// Next in linked list int priority; // Priority };
kfifo is alock-free circular buffer(circular buffer), providing lock-free communication for producer/consumer single-reader/single-writer (multi-reader/multi-writer requires external synchronization).
Header file:<linux/kfifo.h>
Core API:
API
Description
DECLARE_KFIFO(fifo, type, size)
Static Definition
kfifo_alloc(fifo, size, gfp)
Dynamic Allocation
kfifo_put(fifo, val)
Enqueue an Element
kfifo_get(fifo, val)
Dequeue an Element
kfifo_in(fifo, buf, n)
Enqueue Multiple Bytes
kfifo_out(fifo, buf, n)
Dequeue Multiple Bytes
kfifo_is_empty(fifo)
Is Empty
kfifo_is_full(fifo)
Is Full
kfifo_len(fifo)
Number of Used Elements
kfifo_reset(fifo)
Clear Queue
kfifo_free(fifo)
Free Memory
Usage Example:
1 2 3 4 5 6 7 8 9 10
DECLARE_KFIFO(fifo, int, 32);
// Enqueue int val = 42; kfifo_put(&fifo, val);
// Dequeue int out; if (kfifo_get(&fifo, &out)) pr_info("got: %d\n", out);
Typical applications in the kernel:
Serial port driver transmit/receive buffers
Audio driver PCM buffer
Kernel log buffer (printk ring buffer)
percpu — Per-CPU variables
Per-CPU variables allocateindependent memory copies for each CPU, CPUs can access their own copies without locking, and cache utilization is extremely high (variables are in the CPU’s local cache).
Header file:<linux/percpu.h>
Core API:
API
Description
DEFINE_PER_CPU(type, name)
Static definition
alloc_percpu(type)
Dynamic allocation
per_cpu(var, cpu)
Access the copy of a specified CPU
get_cpu_var(var)
Get the copy of the current CPU (preemption disabled)
put_cpu_var(var)
Combined with get_cpu_var, restore preemption
this_cpu_ptr(ptr)
Get pointer to this CPU’s copy
per_cpu_ptr(ptr, cpu)
Get pointer to the specified CPU’s copy
for_each_possible_cpu(cpu)
Iterate over all CPUs
Usage example:
1 2 3 4 5 6 7 8 9
staticDEFINE_PER_CPU(int, my_counter);
// Increment this CPU's counter — no locking required int cpu = get_cpu(); per_cpu(my_counter, cpu)++; put_cpu();
// A more concise way (better performance) this_cpu_inc(my_counter);
A set of simple macros for using ordinary character arrays as circular buffers. Commonly used to implement lightweight producer/consumer queues.
Header file:<linux/circ_buf.h>
Data structure:
1 2 3 4 5
structcirc_buf { char *buf; int head; // Producer write position int tail; // Consumer read position };
Core macro:
Macro
Description
CIRC_SPACE(head, tail, size)
Available space
CIRC_CNT(head, tail, size)
Used bytes
CIRC_SPACE_TO_END(head, tail, size)
Contiguous space to the end of the buffer
Typical applications in the kernel:
TTY driver line discipline buffer
Simple serial port driver
flex_array — flexible array
flex_array Allows creatingArray spanning multiple pages, but each element has a fixed size. Compared to a single kmalloc large chunk of memory,flex_array it is more tolerant of small memory fragments (because each element is distributed across different pages).
warning
Starting from Linux 5.10,flex_array it has been marked as deprecated, and it is recommended to use ordinary kmalloc_array or kvmalloc_array instead.
Header file:<linux/flex_array.h>(deleted)
Alternative:kvmalloc_array(n, size, GFP_KERNEL) will automatically select kmalloc or vmalloc。
page — physical page descriptor
struct page is in Linux memory managementThe most important data structure, each physical memory page has a corresponding page struct.
User space page table mapping (page fault handling)
mm_struct / vm_area_struct — process address space
mm_struct — memory descriptor
Describes a process’scomplete virtual address space, each process has a unique mm_struct(Shareable between threads).
Header file:<linux/mm_types.h>
1 2 3 4 5 6 7 8 9 10 11 12
structmm_struct { structmaple_treemm_mt;// VMA maple tree (6.1+) structvm_area_struct *mmap;// VMA linked list head unsignedlong task_size; // Address space size pgd_t *pgd; // Page Global Directory atomic_t mm_users; // User count atomic_t mm_count; // Reference count unsignedlong total_vm; // Total page count spinlock_t page_table_lock; structlist_headmmlist;// Global mm_struct linked list // ... };
vm_area_struct — Virtual Memory Area
Describes acontiguous virtual address range, where each range has the same protection attributes and mapping type.
1 2 3 4 5 6 7 8 9 10 11 12
structvm_area_struct { unsignedlong vm_start; // Start address unsignedlong vm_end; // End address (exclusive) structvm_area_struct *vm_next;// Next in linked list pgprot_t vm_page_prot; // Page protection unsignedlong vm_flags; // VM_READ, VM_WRITE, VM_EXEC, etc. structrb_nodevm_rb;// Red-black tree node (legacy) structmm_struct *vm_mm;// Owning mm_struct conststructvm_operations_struct *vm_ops;// Operations function table structfile *vm_file;// Mapped file // ... };
Typical applications in the kernel:
Page fault handler
mmap() / munmap() System call
/proc/<pid>/maps Information source
Network
sk_buff — Socket buffer
sk_buff(usually abbreviated as skb) is Linux network subsystem’s core data structure, representing a network packet. It runs through the entire network stack: from network card driver reception to application layer transmission, all use sk_buff as the carrier.
]]>This article introduces the core data structures with high practical usage frequency in the Linux 6.x kernel, detailing the definitions, core APIs, and typical use cases of structures such as doubly linked circular lists, hash linked lists, red-black trees, radix trees, extensible arrays, and priority linked lists.ClaudeCodehttps://even629.com/en/posts/202605241/2026-05-24T02:10:13.000Z2026-05-24T02:10:13.000Z Timeline
Timeline
2026-05-24
init
This article introduces the download, installation, and editor integration methods of Claude Code, detailing how to configure and use it with the DeepSeek API in VSCode and Emacs. Additionally, it discusses Claude Code's Skill extension mechanism, the MCP model context protocol, as well as the installation of related Skills and recommended plugins.
ClaudeCode
Download Claude Code, requires Node.js
1 2 3 4 5 6 7 8
# It's best to change the source npm config set registry https://registry.npmmirror.com npm install -g @anthropic-ai/claude-code
claude --version
# Restore the session in the current directory claude -c
DeepSeek
Choose DeepSeek here because its tokens are cheaper and don’t require an external network connection. Click the link below to apply for an API key
Download the plugin:Claude Code for VS CodeAnthropic anthropic.com, then find it in the settings@ext:Anthropic.claude-codeunderClaudeCode: Environment VariablesClickEdit in settings.json
Refer to the official documentation to set environment variables
Emacs is generally used in Linux environments; Windows Emacs has too many bugs, so the following configuration is all for the Linux environment. First, still install Claude Code, then set the environment variables.$HOME/.bashrcor$HOME/.zshrc
(use-package monet :vc (:url"https://github.com/stevemolitor/monet":rev:newest))
;; for vterm terminal backend: (use-package vterm :ensuret)
;; install claude-code.el (use-package claude-code :ensuret :vc (:url"https://github.com/stevemolitor/claude-code.el":rev:newest) :config ;; optional IDE integration with Monet (add-hook 'claude-code-process-environment-functions #'monet-start-server-function) (monet-mode1) (setq claude-code-terminal-backend 'vterm) (claude-code-mode) :bind-keymap ("C-c c" . claude-code-command-map) ;; Optionally define a repeat map so that "M" will cycle thru Claude auto-accept/plan/confirm modes after invoking claude-code-cycle-mode / C-c M. :bind (:repeat-map my-claude-code-map ("M" . claude-code-cycle-mode)))
EnterC-c c cto start the Claude Code window. Other commands can be viewed via claude-code-transient (C-c c m).
Skill
Skill is an extension mechanism for Claude Code launched by Anthropic in October 2025. It can be understood as a skill pack for Claude Code, essentially a Markdown file.SKILL.mdIt contains the purpose, prompts, rules, and workflow of this Skill. Its storage location:
Project-level directory, which is under your project root directory${workspaceFolder}/.claude/skills/Skills placed here only take effect in the current project, suitable for skills strongly tied to the project, such as project-specific code conventions, deployment processes, etc.
User-level directory, which is the directory under your home folder$HOME/.claude/skills/Skills placed here are available in all projects, suitable for general skills unrelated to specific projects, such as making PPTs, writing documents, formatting WeChat public accounts, etc.
Another concept is MCP (Model Context Protocol). MCP is a standard protocol that allows AI assistants to safely interact with the external world. For example, enabling AI to read local files on your computer, operate GitHub repositories, query databases, send Slack messages, control browsers, etc.
Install Skills as follows:
Manual copySKILL.mdto the project-level directory or user-level directory
The official Anthropic marketplace (claude-plugins-official) is automatically available when starting Claude Code. Run /plugin and go to the Discover tab to browse available content, orclaude.com/pluginsview the directory.
1 2 3
/plugin install github@claude-plugins-official
# Afterwards, you can manage plugins via /plugin
Recommended Skills to install Karpathy-Inspired Claude Code Guidelines:
]]>This article introduces the download, installation, and editor integration methods of Claude Code, detailing how to configure and use it with the DeepSeek API in VSCode and Emacs. Additionally, it discusses Claude Code's Skill extension mechanism, the MCP model context protocol, as well as the installation of related Skills and recommended plugins.smatchhttps://even629.com/en/posts/202605211/2026-05-21T15:10:13.000Z2026-05-21T15:10:13.000Z Timeline
Timeline
2026-05-21
init
This article introduces Smatch, a static analysis tool designed specifically for the Linux kernel, detailing its compilation method, database construction process, and its ability to discover hidden bugs through cross-file analysis. Additionally, it summarizes the specific steps for running Smatch to perform static analysis on kernel and non-kernel projects, along with the configuration methods for related script parameters.
Smatch is a static analysis tool designed specifically for the Linux kernel, capable of deeply tracing code execution paths to uncover deeply hidden bugs, such as null pointer dereferences, lock usage errors, resource leaks, etc. Reference documentation:
# Install Dependencies sudo apt-get install sqlite3 libsqlite3-dev libdbd-sqlite3-perl # Compile Smatch cd ~/repository/linux/ wget https://github.com/error27/smatch/archive/refs/tags/1.74.tar.gz -O smatch-1.74.tar.gz cd smatch-1.74 make -j$(nproc)
kernel
Smatch essentially follows the kernel build system, so it must be able to correctly locate the compiler and header files. Therefore, if cross-compilation is needed, environment variables must be set first.
# Compile Linux make defconfig make -j$(nproc) Image
# Static Analysis and Database Construction ~/repository/linux/smatch-1.74/smatch_scripts/build_kernel_data.sh
build_kernel_data.shwill append--call-tree, --info, --spammy, --data=$DATA_DIRparameter callsmatch_scripts/test_kernel.sh, then callsmatch_data/db/create_db.shbuild Smatch database
Smatch does not require building a database, but building one makes it more powerful. Once the database is built, the next time you compile, Smatch can look up information such as ‘how many times the printk function is called throughout the kernel’ or ‘whether a certain struct pointer has been freed in other C files,’ enabling epic cross-file vulnerability detection.
Run smatch for static analysis of the kernel: Run smatch to check the entire kernel
When running, smatch reads some rules set in smatch_data, in~/repository/linux/smatch-1.74/smatch.cmiddlestatic char *get_data_dir(char *arg0)there is related logic: you can pass--data=/path/to/smatch_dataSpecify
out-of-tree module
For non-kernel projects, use the following method to build the database and analyze
When the --file-output parameter is used, smatch will not print warnings directly to the terminal’s stdout/stderr by default, but will instead generate a bunch of hidden text files in the same directory as your code:
.hello_world.c.smatch(General warnings)
.hello_world.c.smatch.caller_info(If you added parameters like --info)
]]>This article introduces Smatch, a static analysis tool designed specifically for the Linux kernel, detailing its compilation method, database construction process, and its ability to discover hidden bugs through cross-file analysis. Additionally, it summarizes the specific steps for running Smatch to perform static analysis on kernel and non-kernel projects, along with the configuration methods for related script parameters.Query the earliest version where a kernel API was introducedhttps://even629.com/en/posts/202605210/2026-05-21T15:08:13.000Z2026-05-21T15:08:13.000Z Timeline
Timeline
2026-05-21
init
This article describes how to query the earliest version where a specific kernel API was introduced, and illustrates the query method with concrete examples.
How to check which version introduced a certain kernel API? Takearray_index_nospecas an example
1 2 3 4 5 6 7 8 9 10
git clone https://github.com/torvalds/linux.git
# Find its definition in include/linux/nospec git blame include/linux/nospec.h
# Find the commit ID git show f3804203306e0
# Check all tags containing this commit ID git tag --contains f3804203306e0
]]>This article describes how to query the earliest version where a specific kernel API was introduced, and illustrates the query method with concrete examples.LeetCode Daily Problem P3546 Equal Sum Matrix Partition Ihttps://even629.com/en/posts/3546/2026-03-25T02:28:13.000Z2026-03-25T02:28:13.000Z Timeline
classSolution { public: boolcanPartitionGrid(vector<vector<int> > &grid) { // 1 <= m == grid.length <= 105 // 1 <= n == grid[i].length <= 105 // 2 <= m * n <= 105 // 1 <= grid[i][j] <= 105 int i, j, m = grid.size(), n = grid[0].size(); int total = m * n; long last; vector<long> prefix_sum(total, 0); vector<long> suffix_sum(total, 0);
// Horizontal partition last = grid[0][0]; for (i = 0; i < m; i++) { for (j = 0; j < n; j++) { if (i == 0 && j == 0) continue; prefix_sum[i * n + j] = last + prefix_sum[i * n + j - 1]; last = grid[i][j]; } }
last = grid[m - 1][n - 1]; for (i = m - 1; i >= 0; i--) { for (j = n - 1; j >= 0; j--) { if (i == m - 1 && j == n - 1) continue; suffix_sum[i * n + j] = last + suffix_sum[i * n + j + 1]; last = grid[i][j]; } }
for (i = 0; i < m - 1; i++) { if (prefix_sum[i * n + n - 1] + grid[i][n - 1] == suffix_sum[i * n + n - 1]) returntrue; }
// Vertical partition prefix_sum[0] = 0; last = grid[0][0]; for (j = 0; j < n; j++) { for (i = 0; i < m; i++) { if (i == 0 && j == 0) continue; prefix_sum[j * m + i] = last + prefix_sum[j * m + i - 1]; last = grid[i][j]; } }
suffix_sum[total - 1] = 0; last = grid[m - 1][n - 1]; for (j = n - 1; j >= 0; j--) { for (i = m - 1; i >= 0; i--) { if (i == m - 1 && j == n - 1) continue; suffix_sum[j * m + i] = last + suffix_sum[j * m + i + 1]; last = grid[i][j]; } } for (j = 1; j < n; j++) { if (prefix_sum[j * m] == suffix_sum[j * m] + grid[0][j]) returntrue; }
returnfalse; } };
]]>Prefix sumLeetCode Daily Problem P2906 Construct Product Matrixhttps://even629.com/en/posts/2906/2026-03-24T09:01:13.000Z2026-03-24T09:01:13.000Z Timeline
classSolution { public: vector<vector<int> > constructProductMatrix(vector<vector<int> > &grid) { // 1 <= n == grid.length <= 105 // 1 <= m == grid[i].length <= 105 // 2 <= n * m <= 105 // 1 <= grid[i][j] <= 109 int i, j, m = grid.size(), n = grid[0].size(); int total = m * n, last; vector<vector<int> > product_matrix(m, (vector<int>(n, 0))); vector<int> prefix_product(total, 1); vector<int> suffix_product(total, 1);
// prefix last = grid[0][0]; for (i = 0; i < m; i++) { for (j = 0; j < n; j++) { if (i == 0 && j == 0) continue;
prefix_product[i * n + j] = (long)((long)last * (long)prefix_product[i * n + j - 1]) % MODULO_NUM; last = grid[i][j]; } } // suffix last = grid[m - 1][n - 1]; for (i = m - 1; i >= 0; i--) { for (j = n - 1; j >= 0; j--) { if (i == m - 1 && j == n - 1) continue; suffix_product[i * n + j] = (long)((long)last * (long)suffix_product[i * n + j + 1]) % MODULO_NUM; last = grid[i][j]; } }
for (i = 0; i < m; i++) { for (j = 0; j < n; j++) { product_matrix[i][j] = (long)((long)prefix_product[i * n + j] * (long)suffix_product[i * n + j]) % MODULO_NUM; } }
return product_matrix; } };
]]>Prefix sumLeetCode Top 100 P1143 Longest Common Subsequencehttps://even629.com/en/posts/1143/2026-03-21T09:09:13.000Z2026-03-21T09:09:13.000Z Timeline
classSolution { public: intuniquePaths(int m, int n) { int i, j; vector<vector<int> > dp(m, vector<int>(n, 0)); // dp[i][j] represents the total number of unique paths to (i,j) for (i = 0; i < m; i++) dp[i][0] = 1;
for (j = 0; j < n; j++) dp[0][j] = 1;
for (i = 1; i < m; i++) { for (j = 1; j < n; j++) dp[i][j] = dp[i - 1][j] + dp[i][j - 1]; }
return dp[m - 1][n - 1]; } };
]]>Dynamic ProgrammingLeetCode Top 100 P32 Longest Valid Parentheseshttps://even629.com/en/posts/32/2026-03-21T06:22:13.000Z2026-03-21T06:22:13.000Z Timeline
Sum the array, then divide the sum by 2, transforming the problem into finding a subset of the array that equals half of the total sum, which is the 0-1 knapsack problem
dp[i][j] represents whether there exists a selection of some positive integers (can be 0) from the index range [0, i] of the array such that the sum of the selected positive integers equals j. Initially, all elements in dp are false.
Initialization:
If no positive integers are selected, the sum of the selected positive integers equals 0. Therefore, for all 0 ≤ i < n, dp[i][0] = true.
When i == 0, only one positive integer nums[0] can be selected, so dp[0][nums[0]] = true.
classSolution { public: boolcanPartition(vector<int> &nums) { int i, j, n = nums.size(); int sum = 0, target;
for (i = 0; i < n; i++) sum += nums[i];
if (sum % 2 != 0) // Odd number returnfalse;
target = sum / 2;
for (i = 0; i < n; i++) { // There is a number exceeding half of the total sum if (nums[0] > target) returnfalse; }
// 0-1 Knapsack Problem // dp[i][j] indicates whether it is possible to select some positive integers (can be 0) from the index range [0, i] of the array // such that the sum of the selected positive integers equals j. Initially, all elements in dp are false. vector<vector<bool> > dp(n, vector<bool>(target + 1, false));
// If no positive integers are selected, the sum of the selected positive integers equals 0. Therefore, for all 0 ≤ i < n, dp[i][0] = true. for (i = 0; i < n; i++) dp[i][0] = true; // When i == 0, only one positive integer nums[0] can be selected, so dp[0][nums[0]] = true. dp[0][nums[0]] = true;
]]>Dynamic ProgrammingLeetCode Hot 100 P152 Maximum Product Subarrayhttps://even629.com/en/posts/152/2026-03-21T02:44:13.000Z2026-03-21T02:44:13.000Z Timeline
#include<vector> #include<algorithm> using std::vector;
classSolution { public: intmaxProduct(vector<int> &nums) { int i, n = nums.size(); int max_val = nums[0]; // dp[i][0] represents the non-empty contiguous subarray ending at nums[i] with the maximum product // dp[i][1] represents the non-empty contiguous subarray ending at nums[i] with the minimum product // dp[i][0] = max{ dp[i-1][0] * nums[i],dp[i-1][1] *nums[i] , nums[i]} // dp[i][1] = min{ dp[i-1][0] * nums[i],dp[i-1][1] *nums[i] , nums[i]}
