关于内核的xxx_initcall

最新推荐文章于 2024-06-05 16:07:01 发布
转载 最新推荐文章于 2024-06-05 16:07:01 发布 · 567 阅读 · 1

本文深入探讨了Linux内核中的subsys_initcall()宏及其工作原理，详细介绍了它是如何组织和调用初始化函数的，以及这些函数在系统启动过程中的执行时机。

在内核代码里到处都能看到这个subsys_initcall()，而它到底是干什么的呢？让我们来揭开它的神秘面纱。

 

先来看一段代码：

---------------------------------------------------------------------

include/linux/init.h

174 /*

175  * Early initcalls run before initializing SMP.

176  *

177  * Only for built-in code, not modules.

178  */

179 #define early_initcall(fn)    __define_initcall("early",fn,early)

180

181 /*

182  * A "pure" initcall has no dependencies on anything else, and purely

183  * initializes variables that couldn't be statically initialized.

184  *

185  * This only exists for built-in code, not for modules.

186  */

187 #define pure_initcall(fn)              __define_initcall("",fn,0)

188

189 #define core_initcall(fn)             __define_initcall("1",fn,1)

190 #define core_initcall_sync(fn)      __define_initcall("1s",fn,1s)

191 #define postcore_initcall(fn)         __define_initcall("2",fn,2)

192 #define postcore_initcall_sync(fn)  __define_initcall("2s",fn,2s)

193 #define arch_initcall(fn)             __define_initcall("3",fn,3)

194 #define arch_initcall_sync(fn)      __define_initcall("3s",fn,3s)

195 #define subsys_initcall(fn)           __define_initcall("4",fn,4)

196 #define subsys_initcall_sync(fn)    __define_initcall("4s",fn,4s)

197 #define fs_initcall(fn)               __define_initcall("5",fn,5)

198 #define fs_initcall_sync(fn)        __define_initcall("5s",fn,5s)

199 #define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)

200 #define device_initcall(fn)           __define_initcall("6",fn,6)

201 #define device_initcall_sync(fn)    __define_initcall("6s",fn,6s)

202 #define late_initcall(fn)             __define_initcall("7",fn,7)

203 #define late_initcall_sync(fn)      __define_initcall("7s",fn,7s)

---------------------------------------------------------------------

类似于subsys_initcall()还有很多，但它们都依赖于__define_initcall()，再来看__define_initcall()的定义：

---------------------------------------------------------------------

include/linux/init.h

 

131 typedef int (*initcall_t)(void);

 

165  *

166  * The `id' arg to __define_initcall() is needed so that multiple

167  * initcalls can point at the same handler without causing duplicate-symbol build errors.

168  */

169

170 #define __define_initcall(level,fn,id) \

171       static initcall_t __initcall_##fn##id __used \

172       __attribute__((__section__(".initcall" level ".init"))) = fn

173

---------------------------------------------------------------------

__define_initcall()宏只是定义一个initcall_t类型的静态变量，并且声明要把这个静态变量放在特定的段里而已。上面我们看到initcall_t即是指向一个无参数有int返回值的函数的指针。

 

许多的子系统都有自己的初始化函数，而这些初始化的函数又根据功能不同被分开在不同的子段里，子段的排列顺序则由链接决定。为了向后兼容，initcall()把调用，也就是一个个指向初始化函数的函数指针放进设备初始化子段里。

 

在各个平台的链接脚本文件arch/xxx/kernel/vmlinux.lds.S中，我们总能看到下面的语句：

INIT_CALLS

这个宏有如下的定义：

---------------------------------------------------------------------

include/asm-generic/vmlinux.lds.h

606 #define INIT_CALLS                                           \

607                 VMLINUX_SYMBOL(__initcall_start) = .;        \

608                 INITCALLS                                    \

609                 VMLINUX_SYMBOL(__initcall_end) = .;

---------------------------------------------------------------------

INIT_CALLS即是定义一个新的段，而定义段的字段的任务则由宏INITCALLS完成：

---------------------------------------------------------------------

include/asm-generic/vmlinux.lds.h

585 #define INITCALLS                                            \

586         *(.initcallearly.init)                               \

587         VMLINUX_SYMBOL(__early_initcall_end) = .;            \

588         *(.initcall0.init)                                   \

589         *(.initcall0s.init)                                  \

590         *(.initcall1.init)                                   \

591         *(.initcall1s.init)                                  \

592         *(.initcall2.init)                                   \

593         *(.initcall2s.init)                                  \

594         *(.initcall3.init)                                   \

595         *(.initcall3s.init)                                  \

596         *(.initcall4.init)                                   \

597         *(.initcall4s.init)                                  \

598         *(.initcall5.init)                                   \

599         *(.initcall5s.init)                                  \

600         *(.initcallrootfs.init)                              \

601         *(.initcall6.init)                                   \

602         *(.initcall6s.init)                                  \

603         *(.initcall7.init)                                   \

604         *(.initcall7s.init)

---------------------------------------------------------------------

 

而这些初始化函数又是在何时调用的呢？我们看到start_kernel()-> rest_init()-> kernel_init()-> do_basic_setup(void)-> do_initcalls()，而正是do_initcalls()处理了这些初始化函数，其定义为：

---------------------------------------------------------------------

init/main.c

765 extern initcall_t __initcall_start[], __initcall_end[], __early_initcall_end[];

766

767 static void __init do_initcalls(void)

768 {

769         initcall_t *fn;

770

771         for (fn = __early_initcall_end; fn < __initcall_end; fn++)

772                 do_one_initcall(*fn);

773

774         /* Make sure there is no pending stuff from the initcall sequence */

775         flush_scheduled_work();

776 }

---------------------------------------------------------------------

do_initcalls()又调用do_one_initcall()函数类处理这些调用。

---------------------------------------------------------------------

init/main.c

715 static char msgbuf[64];

716 static struct boot_trace_call call;

717 static struct boot_trace_ret ret;

718

719 int do_one_initcall(initcall_t fn)

720 {

721      int count = preempt_count();

722      ktime_t calltime, delta, rettime;

723

724      if (initcall_debug) {

725         call.caller = task_pid_nr(current);

726         printk("calling  %pF @ %i\n", fn, call.caller);

727         calltime = ktime_get();

728         trace_boot_call(&call, fn);

729         enable_boot_trace();

730     }

731

732     ret.result = fn();

733

734     if (initcall_debug) {

735        disable_boot_trace();

736        rettime = ktime_get();

737        delta = ktime_sub(rettime, calltime);

738        ret.duration = (unsigned long long) ktime_to_ns(delta) >> 10;

739        trace_boot_ret(&ret, fn);

740        printk("initcall %pF returned %d after %Ld usecs\n", fn,

741        ret.result, ret.duration);

742     }

743

744     msgbuf[0] = 0;

745

746     if (ret.result && ret.result != -ENODEV && initcall_debug)

747        sprintf(msgbuf, "error code %d ", ret.result);

748

749     if (preempt_count() != count) {

750        strlcat(msgbuf, "preemption imbalance ", sizeof(msgbuf));

751        preempt_count() = count;

752     }

753     if (irqs_disabled()) {

754        strlcat(msgbuf, "disabled interrupts ", sizeof(msgbuf));

755        local_irq_enable();

756     }

757     if (msgbuf[0]) {

758        printk("initcall %pF returned with %s\n", fn, msgbuf);

759     }

760

761     return ret.result;

762 }

---------------------------------------------------------------------

lcqlw123
关注
linux驱动开发扩展--module_init与subsys_initcall详解
linux驱动开发大纲
11-05 1726
__init include/linux/init.h #define __init __section(.init.text) __cold notrace 将用__init修饰的函数放到.init.text段（通过后面的分析可以知道这个段里的东西在被初始化时调用一次之后为了节省内存就被释放掉了） #define __cold __attribute__((__cold__))。函数前面使用这个扩展，表示该函数比较冷门，这样在分支预测机制里就不会对该函数进行预取，或说是...
对于内核中各种xxx_initcall调用的分析———linux子系统初始化
fridayLL的专栏
05-17 2235
对应内核版本  linux-2.6.32.63, 架构arm（版本较老，但已经属于2.6以后的版本了）。 一、 xxx_initcall是一系列子系统的初始化入口函数 对应文件include/linux/init.h #define early_initcall(fn)           __define_initcall("early",fn,early) #de
说说subsys_initcall
11-21 8856
 在linux内核代码里， 到处充满了subsys_initcall，这个调用是用来干吗的呢？有人回答是系统启动时候用来初始化某些系统的，具体怎么初始化的呢，说起来还是有点复杂。以2.6.21内核作为例子。在linux/init.h里，有这样一段代码：#define pure_initcall(fn)  __define_initcall("0",fn,1)#define core_i
__define_initcall(level,fn)
05-30 1196
在linux的驱动里经常会出现__define_initcall(level,fn)的用法,特别是在驱动,的init函数中,譬如I2C_ADAPTER的驱动有这样的函数subsys_initcall(imapx200_i2c_adap_init);关于它的具体用法,就参考下面的资料宏定义__define_initcall(level,fn)对于内核的初始化很重要，他指示编译器在编译的时候，将一系列初始化函数的起始地址值按照一定的顺序放在一个section中。在内核初始化段，do_initcalls() 将按
《Linux内核修炼之道》精华分享与讨论（16）——子系统的初始化：那些入口函数...
weixin_33971130的博客
05-18 287
内核选项的解析完成之后，各个子系统的初始化即进入第二部分—入口函数的调用。通常USB、PCI这样的子系统都会有一个名为subsys_initcall的入口，如果你选择它们作为研究内核的切入点，那么就请首先找到它。 ×××庸在《关于上班这件事》里说，要花前半生找入口，花后半生找出口。可见寻找入口对于咱们这一生，对于看内核代码这件事儿都是无比重要的。 但是很多时候，入口...
subsys_initcall
weixin_42082222的博客
03-07 2712
subsys_initcall linux子系统的初始化_subsys_initcall()：那些入口函数【转】 https://blog.youkuaiyun.com/u010388659/article/details/81265010 内核选项的解析完成之后，各个子系统的初始化即进入第二部分—入口函数的调用。通常USB、PCI这样的子系统都会有一个名为subsys_initcall的...
内核常见宏定义| module_init 详解必看
weixin_44458100的博客
06-05 1509
module_init驱动如何初始化
linux内核链接脚本vmlinux.lds分析续篇之 --- initcall机制（十三）
旺旺旺的大黄的博客
05-27 1025
linux的initcall机制(针对编译进内核的驱动)
linux 内核动态模块初始化 __attribute__((section(XXX)))
bie_niu1992的专栏
08-20 896
一 概述 传统的应用编写时，每添加一个模块，都需要在main中添加新模块的初始化。也就是说增加的一个不能算是真正的独立模块，得在main中修改代码才能集成这模块功能。有没有什么办法可以实现main跟其他模块之间隔离呢？main不再关心有什么模块，模块的删减也不需要修改main？ 二 liunx内核模块初始化 如果你对liunx模块有一定了解，你应该知道liunx模块都是独立加载，加载模块，不需要修...
Linux init机制
m0_49328056的博客
03-14 641
一、init机制 我们都知道，linux对驱动程序提供静态编译进内核和动态加载两种方式，当我们试图将一个驱动程序编译进内核时，开发者通常提供一个xxx_init()函数接口以启动这个驱动程序同时提供某些服务。那么，根据常识来说，这个xxx_init()函数肯定是要在系统启动的某个时候被调用，才能启动这个驱动程序。最简单直观地做法就是：开发者试图添加一个驱动程序时，在内核启动init程序的某个地方直接添加调用自己驱动程序的xxx_init()函数，在内核启动时自然会调用到这个程序。但是，回头一想，这种做法在
subsys_initcall();
为啥而非
08-05 438
我们看到一个 subsys_initcall,它是一个宏,我们可以把它理解为module_init,只不过因为这部分代码比较核心,开发者们把它看作一个子系统,而不仅仅是一个模块,这也很好 理解,usbcore这个模块它代表的不是某一个设备,而是所有usb设备赖以生存的模块,Li
神秘的subsys_initcall
Liuqz2009的专栏
03-03 569
 在内核代码里到处都能看到这个subsys_initcall()，而它到底是干什么的呢？让我们来揭开它的神秘面纱。   先来看一段代码： --------------------------------------------------------------------- include/linux/init.h 174 /* 175  * Early initcalls
神秘的subsys_initcall[转]
weixin_30588729的博客
08-19 202
原文链接:http://blog.chinaunix.net/uid-12567959-id-161015.html 在内核代码里到处都能看到这个subsys_initcall()，而它到底是干什么的呢？让我们来揭开它的神秘面纱。 先来看一段代码： ---------------------------------------------------------------------...
arch_initcall
micro9981的专栏
10-08 517
arch_initcall是在include/linux目录下init.h中定义的宏定义。arch_initcall(board_init) 通过调用arch_initcall这个宏定义来登记板上设备，比如MTD NAND,USB等，包括MTD空间分区地址分配。http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:customizin...
系统初始化函数集(subsys_initcall)和初始化段应用
liaojunwu的博客
02-07 1299
参考博文: https://blog.youkuaiyun.com/jackaly/article/details/7426353 https://blog.youkuaiyun.com/qlexcel/article/details/92656797 1.函数定义(subsys_initcall/late_initcall是什么) 内核代码4.14.99/include/linux/init.h，需要注意的是这里只针对build-in code，所以代码加上了#ifndef MODULE的限制 我们用C代码
【Android底层学习总结】4. 内核中do_initcalls函数源码解析
Alexander的博客
03-30 452
1 前言 本节内容主要对do_initcalls函数进行总结，老实说这个函数有点复杂，需要了解汇编知识以及C语言里面对宏、函数指针的高级用法的理解。我在总结这篇文章时候都有点云里雾里，参考了网上很多老前辈的博客。如果本篇有什么错误，还请大家积极指正，谢谢大家。 2 源码解析 注：本篇代码取自kernel4.9 /*做初始化工作，代码路径：init/main.c */ static void __init do_initcalls(void) { int level; // 按照级别调用初始化函数，le
kernel的initcall函数
华的专栏
01-30 620
initcall函数的声明： /* include/linux/init.h */ /* initcalls are now grouped by functionality into separate   * subsections. Ordering inside the subsections is determined  * by link order.   * For ba
能否在内核运行其他驱动之前,先运行这个驱动
最新发布
10-14
<think>我们需要确保驱动在内核启动早期加载，以便其他依赖该驱动的模块可以正常使用。在Linux内核中，驱动的加载顺序主要由以下因素决定： 1. 内核初始化级别：通过指定驱动的初始化函数到不同的初始化级别（如`arch_initcall`、`subsys_initcall`、`device_initcall`等） 2. 模块依赖关系：使用MODULE_SOFTDEP在模块中声明软依赖 然而，您的要求是“在内核运行其他驱动之前”先运行这个驱动，这通常意味着我们希望这个驱动在系统启动的早期阶段就被初始化。 解决方案： 1. 将驱动编译进内核（而不是作为模块），并指定较高的初始化优先级（如`subsys_initcall`或`arch_initcall`）。 2. 如果必须作为模块加载，则需要在系统启动脚本中确保该模块在其它模块之前被加载（例如，在/etc/modules中靠前，或者在initramfs中提前加载）。 具体修改步骤： 方法一：编译进内核（推荐确保早期加载） - 在Kconfig中添加配置选项，并在Makefile中编译该驱动。 - 在驱动源文件中，将初始化函数标记为`subsys_initcall`（内核初始化阶段较早）或`arch_initcall`（更早）。 方法二：作为模块加载，但强制早期加载 - 使用`module_init`声明初始化函数，但通过修改启动脚本确保首先加载此模块。 这里我们主要讨论方法一，因为编译进内核可以确保在系统启动的早期阶段初始化。 修改驱动代码： 将原来的`module_platform_driver`改为手动注册，并使用`subsys_initcall`。 步骤： 1. 移除`module_platform_driver`宏 2. 定义驱动注册和注销函数 3. 使用`subsys_initcall`指定初始化函数，使用`module_exit`指定退出函数（即使编译进内核，退出函数不会被调用，但保留以便作为模块时使用） 修改后的驱动代码（关键部分）： ```c // ... 前面的代码保持不变 ... // 移除: module_platform_driver(dhsocdev_driver); static int __init dhsocdev_driver_init(void) { return platform_driver_register(&dhsocdev_driver); } static void __exit dhsocdev_driver_exit(void) { platform_driver_unregister(&dhsocdev_driver); } // 使用subsys_initcall来确保早期初始化 subsys_initcall(dhsocdev_driver_init); module_exit(dhsocdev_driver_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("Driver for dhtest,soc-dev device"); MODULE_VERSION("1.0"); ``` 这样，当驱动被编译进内核时，它会在子系统初始化阶段被调用，这个阶段在大多数设备驱动初始化之前（除了那些使用更早初始化级别的，如arch_initcall）。 注意：如果您的驱动依赖于其他更底层的驱动（例如时钟控制器、中断控制器等），则不能过早初始化。在这种情况下，您可能需要依赖内核的初始化顺序，或者使用设备树机制来确保正确的初始化顺序。 另一种方法：使用设备树中的initcall优先级（新版本内核） - 在设备树节点中添加`linux,initcall-debug`属性，但这主要用于调试，并不直接控制顺序。 总结： - 对于需要在内核启动早期运行的驱动，将其编译进内核并设置为`subsys_initcall`或`arch_initcall`。 - 如果依赖其他驱动，则不能早于被依赖的驱动初始化，此时需要通过内核的initcall顺序自然处理。 最后，如果您的驱动是为特定硬件平台（如ARM SoC）编写的，可以考虑将驱动放到`arch/arm/mach-xxx`下的特定板级文件中，并在该平台的早期初始化函数中注册平台设备。 但是，由于您使用的是平台设备驱动框架，上面修改为`subsys_initcall`的方法是最直接的。 另外，如果您的设备是一个关键设备（例如系统时钟），可能需要更早的初始化，那么可能需要将其标记为`arch_initcall`。不过请注意，`arch_initcall`阶段的资源可能还不完整（如内存分配器可能还没准备好），因此要谨慎。 建议： - 如果不依赖于其他驱动，使用`subsys_initcall`足够早。 - 如果需要在设备模型初始化之前就初始化，可能需要使用`early_platform`机制（但这种情况较少见）。 因此，按照上述修改即可。 注意：如果驱动作为模块加载，则`subsys_initcall`无效，因为模块加载时使用`module_init`（等同于`device_initcall`）。所以，确保驱动编译进内核是关键。 如果必须作为模块，那么只能通过系统启动脚本控制加载顺序。 例如，在构建initramfs时，将模块放入initramfs，并在init脚本中首先加载该模块。或者在系统中使用`/etc/modules`文件，将模块名放在文件开头。 但模块加载顺序控制不如编译进内核可靠。 因此，如果要求在内核运行其他驱动之前运行，强烈建议编译进内核并使用`subsys_initcall`。 修改后的完整驱动代码示例（只展示修改部分）： ```c // ... 前面的代码不变 ... // 移除 module_platform_driver(dhsocdev_driver); static int __init dhsocdev_driver_init(void) { return platform_driver_register(&dhsocdev_driver); } static void __exit dhsocdev_driver_exit(void) { platform_driver_unregister(&dhsocdev_driver); } // 使用subsys_initcall确保在子系统初始化阶段加载 subsys_initcall(dhsocdev_driver_init); module_exit(dhsocdev_driver_exit); ``` 这样，当内核启动时，该驱动将在较早的阶段被初始化。 §§相关问题§§: 1. Linux内核中不同的初始化级别（如arch_initcall, subsys_initcall）有哪些？它们的顺序是怎样的？ 2. 如何在内核驱动中处理模块之间的依赖关系？ 3. 如果两个驱动都需要早期初始化且存在依赖关系，如何解决？ 4. 如何在ARM平台设备树中指定设备的初始化顺序？ </think>是的，可以通过修改内核启动顺序，确保您的驱动在内核初始化阶段优先于其他驱动运行。这里有几种实现方法： ### 方法1：使用`subsys_initcall`宏（推荐） 这是最常见且标准的方法，通过指定初始化级别确保驱动优先加载： ```c #include <linux/init.h> // 替换原来的 module_init subsys_initcall(dhsocdev_driver_init); // 保持原来的 module_exit module_exit(dhsocdev_driver_exit); ``` #### Linux内核初始化级别顺序： 1. `pure_initcall` - 最早的初始化 2. `core_initcall` 3. `postcore_initcall` 4. `arch_initcall` 5. `subsys_initcall` ← 推荐级别 6. `fs_initcall` 7. `device_initcall` - 常规驱动级别 8. `late_initcall` ### 方法2：使用`early_initcall`（更早启动） 如果需要更早的初始化（在内存管理系统之前）： ```c early_initcall(dhsocdev_driver_init); ``` ### 方法3：在内核启动参数中指定顺序 在启动参数中明确指定驱动加载顺序： ```c // 在驱动中添加： module_init(dhsocdev_driver_init); module_exit(dhsocdev_driver_exit); // 在启动参数中添加： dhsocdev.custom_init=1 ``` 然后在驱动中处理： ```c static int __init dhsocdev_custom_init(void) { if (!custom_init_param) return -ENODEV; return platform_driver_register(&dhsocdev_driver); } early_param("dhsocdev.custom_init", dhsocdev_custom_init); ``` ### 完整修改后的驱动示例 ```c #include <linux/init.h> // ... [其他头文件保持不变] // ... [device definitions保持不变] static int __init dhsocdev_driver_init(void) { pr_info("DHSOCDEV: EARLY INIT STARTED\n"); // 1. 优先初始化硬件 void __iomem *peri_base = ioremap(0xFF200000, DHSOC_PERI_REGION); if (!peri_base) return -ENOMEM; // 2. 配置关键时钟 iowrite32(VCXO_1_CLK_IN, peri_base + VCXO_1_OFFSET); // 3. 注册平台驱动 int ret = platform_driver_register(&dhsocdev_driver); pr_info("DHSOCDEV: EARLY INIT COMPLETE\n"); return ret; } subsys_initcall(dhsocdev_driver_init); // 早期初始化 module_exit(dhsocdev_driver_exit); ``` ### 确保优先初始化的关键点 1. **硬件依赖处理**： ```c // 在probe之前初始化关键硬件 static int __init dhsocdev_driver_init(void) { // 优先配置时钟和复位 soc_configure_pll(); soc_reset_peripherals(); // 再注册驱动 return platform_driver_register(&dhsocdev_driver); } ``` 2. **解决驱动依赖**： 在`Makefile`中确保依赖关系： ```make obj-$(CONFIG_DHSOCDEV) += dhsocdev.o dhsocdev-objs := dhsoc_core.o dhsoc_io.o dhsoc_dma.o ``` 3. **内核配置**： 在Kconfig中设置为默认启用： ```kconfig config DHSOCDEV bool "DHSOC Early Init Device" default y depends on ARCH_XYZ help Enable this for early initialization of SOC peripherals ``` ### 验证加载顺序 ```bash # 查看内核初始化顺序 dmesg | grep "initcall" # 预期输出 [ 0.000000] initcall dhsocdev_driver_init+0x0/0x100 [dhsocdev] early [ 5.000000] initcall other_driver_init+0x0/0x80 [other_driver] normal ``` ### 注意事项 1. **资源可用性问题**： - 在`subsys_initcall`阶段，内存管理系统可能尚未完全初始化 - 避免使用`kmalloc()`，改用`memblock_alloc()` ```c #include <linux/memblock.h> void *early_mem = memblock_alloc(size, PAGE_SIZE); ``` 2. **中断处理限制**： - 早期中断处理可能不可用，需要延迟处理 ```c void soc_delayed_irq_setup(struct work_struct *work) { request_irq(priv->irq, dhsocdev_interrupt, IRQF_SHARED, ...); } INIT_DELAYED_WORK(&soc_work, soc_delayed_irq_setup); schedule_delayed_work(&soc_work, msecs_to_jiffies(500)); ``` 3. **并发访问问题**： ```c static DEFINE_SPINLOCK(early_lock); spin_lock(&early_lock); /* 关键操作 */ spin_unlock(&early_lock); ``` ### 替代方案：Initramfs集成 如果需要在用户空间驱动之前初始化： ```bash # 在initramfs中添加 #!/init echo "Mounting early devices" modprobe dhsocdev mount /dev/dhsoc /mnt/socdev ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值