6.s081/6.1810(Fall 2022)Lab2: System calls

这篇具有很好参考价值的文章主要介绍了6.s081/6.1810(Fall 2022)Lab2: System calls。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言

这个lab主要介绍了用户态到内核态的系统调用做了什么,并让我们照猫画虎完成了两个系统调用的实现。

其他篇章

环境搭建
Lab1: Utilities
Lab2: System calls
Lab3: Page tables
Lab4: Traps
Lab5: Copy-on-Write Fork for xv6

参考链接

官网链接
xv6手册链接,这个挺重要的,建议做lab之前最好读一读。
xv6手册中文版,这是几位先辈们的辛勤奉献来的呀!再习惯英文文档阅读我还是更喜欢中文一点,开源无敌!
OSTEP,对OS不熟悉的同学做之前可以看一下这本经典书籍,写得很好,也有中文版实体书。
个人代码仓库
官方文档

0. 前置准备

很惭愧,以前github用得少,这一步折腾了老半天,我再说一遍我个人的开发流程——先在windows下git一个本地仓库,然后用VS编辑,写完后git push上去,在WSL的对应地方git pull下来,然后编译运行。

前面环境配置中我为了连接到我个人的远程仓库,是直接把原本的远程仓库删了的,然后lab1做完做到lab2发现这个lab整体不是循序渐进的,而是彼此分离的,每个实验需要选择相应的分支,因此就要重新弄一下:

 git remote add base  git://g.csail.mit.edu/xv6-labs-2022
 git fetch base
 git checkout syscall
 git push --set-upstream origin syscall

当然,别忘了加.gitignore
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

1. System call tracing (moderate)

1.1 简单分析

gdb教学我就不说了,看看这个task。
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
先简单研究一下我们需求的这个trace是干什么的吧,trace顾名思义,tracing,追踪、寻迹的意思,比如ray tracing,就是光线追踪,这个命令接受一个传参mask,内涵是一个掩码,每一位对应一个系统调用的一个序号,比如传入32,代表 32 1<<SYS_read,2147483647 代表追踪所有syscall,具体的这些值定义在了kernel/syscall.h里,我们待会也会写
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
初步了解之后,就写实现吧,这个task按照hint的步骤来很清晰:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

1.2 Hint 1

Add $U/_trace to UPROGS in Makefile

首先添加makefile,司空见惯了。

1.3 Hint 2

Run make qemu and you will see that the compiler cannot compile user/trace.c, because the user-space stubs for the system call don’t exist yet: add a prototype for the system call to user/user.h, a stub to user/usys.pl, and a syscall number to kernel/syscall.h. The Makefile invokes the perl script user/usys.pl, which produces user/usys.S, the actual system call stubs, which use the RISC-V ecall instruction to transition to the kernel. Once you fix the compilation issues, run trace 32 grep hello README; it will fail because you haven’t implemented the system call in the kernel yet.

然后说这个时候make,会找不到trace,我们要在用户态user/user.h里加上trace的声明,根据原文 It should take one argument, an integer “mask”, whose bits specify which system calls to trace. 可知,这玩意应该接受一个int,然后返回也是一个int(返回值其实不影响来着):
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
然后我们在user/usys.pl下添加这么一行,这是个Perl脚本,即使没有用过Perl的同学应该也能看出来这里的意思是声明了一个trace系统调用的入口,再通过上文展开为我们在usys.S中生成一段汇编代码。
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
然后在内核syscall.h中给它注册一个number
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

1.4 Hint 3

Add a sys_trace() function in kernel/sysproc.c that implements the new system call by remembering its argument in a new variable in the proc structure (see kernel/proc.h). The functions to retrieve system call arguments from user space are in kernel/syscall.c, and you can see examples of their use in kernel/sysproc.c.

然后模仿着添加原型?
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
这里简单解释一下后面这个syscalls数组,可能很多人没有看懂这,首先这是个static的不用说,然后这是个函数指针的数组(我一向很反感那些什么数组指针指针数组混着说的,直接说成装指针的数组不就一目了然了吗),函数返回值为uint64,参数为void,显然是为上面extern的那些函数准备的东西,这些都比较简单,后面的是个小feature了,它本身叫作指派初始化器(Designated Initializers),来自C99,意思就是给方括号里的那一位初始化为右边的值
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
但是可以看到,C99的指派初始化器的形式是[N] = expr的,中间需要一个等号连接,这里没有,它是来自GCC私货,原文出现在介绍指定初始化器的时候:An alternative syntax for this that has been obsolete since GCC 2.5 but GCC still accepts is to write ‘[index]’ before the element value, with no ‘=’. 意味着大家在自己使用时加个等号是更符合standard的写法。
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

然后叫我们仿照着kernel/sysproc.c里的其他函数给trace写一个定义进去:

uint64
sys_trace(void)
{
  
  return 0;
}

使用argint从寄存器取出用户传入的参数:

  int mask;
  argint(0, &mask); // 保存用户传入的参数

然后我们要把接到的这个mask保存到进程的元数据中,根据原文Add a sys_trace() function in kernel/sysproc.c that implements the new system call by remembering its argument in a new variable in the proc structure (see kernel/proc.h). T 我们在kernel/proc.h中可以找到一个结构体struct proc
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
很显然这个结构体记录着一些元数据,我们在这个基础上再添加一条承载mask的:

  int traceMask;               // 用于接收trace的mask

显然每一个进程都有一个独属于自己的proc对象,我们可以通过myproc()来获取这个对象的指针,就此我们可以完成我们的sys_trace定义:

uint64
sys_trace(void)
{
  argint(0, &myproc()->mask); // 尝试从用户空间读取参数
  return 0;
}

1.5 Hint 4

Modify fork() (see kernel/proc.c) to copy the trace mask from the parent to the child process.

我们知道fork出的子进程会复制父进程的内存空间,根据hint我们可以找到它的实现:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
可以看到,这里明显是要做一个pnp的拷贝,p指向的是父进程的proc对象,np则应该是new proc的缩写了:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
我们这个mask的修改不需要持有锁,因此只需要在alloc之后的合适时机将父进程的值赋出即可:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
既然提到了alloc,这里刚好就可以想到一个问题——资源的分配与释放呢?我们知道C语言访问未初始化变量的行为是UB,那么我们默认状态下的mask进行初始化了吗?在上面那张图里我们可以清晰地看到(或者说猜到)内核依赖allocproc分配内存,依赖freeproc释放内存,因此我们可以直接F12进去看一看实现:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
如图,我们可以很容易地为mask初始化以及释放时赋0值。

1.6 Hint 5

Modify the syscall() function in kernel/syscall.c to print the trace output. You will need to add an array of syscall names to index into.

然后我们为syscall这个总体的函数实现我们的功能,也就是前文中的那些打印:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
我们分析一下需要做的事情:当我们进行了trace调用时,我们应当追踪mask标记的所有调用,并打印出4: syscall close -> 0这样的内容,不难看出,打印内容分为三部分:PID、系统调用的名称与系统调用的返回值,其中pid我们可以通过读取proc来获取,返回值实际在框架中都告诉你了:

    // and store its return value in p->trapframe->a0
    p->trapframe->a0 = syscalls[num]();

可以看到,系统调用的返回值被保存在了寄存器a0中,至于系统调用的名称呢?C语言中没有反射,我们就只好提前建立一张syscall的名称表,再根据mask去寻址:

// 系统调用的名称
static const char *syscallnames[] = {
[SYS_fork]    "fork",
[SYS_exit]    "exit",
[SYS_wait]    "wait",
[SYS_pipe]    "pipe",
[SYS_read]    "read",
[SYS_kill]    "kill",
[SYS_exec]    "exec",
[SYS_fstat]   "fstat",
[SYS_chdir]   "chdir",
[SYS_dup]     "dup",
[SYS_getpid]  "getpid",
[SYS_sbrk]    "sbrk",
[SYS_sleep]   "sleep",
[SYS_uptime]  "uptime",
[SYS_open]    "open",
[SYS_write]   "write",
[SYS_mknod]   "mknod",
[SYS_unlink]  "unlink",
[SYS_link]    "link",
[SYS_mkdir]   "mkdir",
[SYS_close]   "close",
[SYS_trace]   "trace",
};

搞清楚并完成了所有前置工作我们就可以开始写逻辑了,最后的syscall函数代码,很简单:

void
syscall(void)
{
  int num;
  struct proc *p = myproc();

  num = p->trapframe->a7;
  if(num > 0 && num < NELEM(syscalls) && syscalls[num]) {
    // Use num to lookup the system call function for num, call it,
    // and store its return value in p->trapframe->a0
    p->trapframe->a0 = syscalls[num]();
    if ((p->mask >> num) & 1) { // 判断系统调用是否被跟踪
      printf("%d: syscall %s -> %d\n",
              p->pid, syscallnames[num], p->trapframe->a0);
    }
  } else {
    printf("%d %s: unknown sys call %d\n",
            p->pid, p->name, num);
    p->trapframe->a0 = -1;
  }
}

1.7 测试

到这里就基本完成了,还是老规矩,我们make qemu编译,然后试一试文档中的几个命令:

trace 32 grep hello README

6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

trace 2147483647 grep hello README

6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

grep hello README

trace 2 usertests forkforkfork # 这一条输入之后貌似要等一会才会出一大坨

6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统


6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

最后跑一下总体批分./grade-lab-syscall trace
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
成功通过!

2. Sysinfo (moderate)

然后让我们来完成一下task2,这个是也是添加一个系统调用,叫sysinfo
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
我们先搞清楚这个调用是干啥的,从介绍可以看到,这个sysinfo接收一个struct sysinfo的指针,我们就是要写这个指针指向的对象,怎么写呢?就是将空闲的字节数存到对象里的freemem字段,将state不为UNUSED的进程数量写到nproc字段。

有一个初步的印象后就可以去写实现了,整体思路和上文trace的步骤差不多:

首先是增加$U/_sysinfotest\到Makefile:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

2.1 声明

user/user.h里加声明:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
syscall.h中:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
syscall.c中(第三个是上面的那个名称表):
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

2.2 实现

2.2.1 框架

写完了声明,就可以写实现了,实现我们依旧写在sysproc.c下:

#include "sysinfo.h" // 由于要接收sysinfo类型的结构体,我们先include一下

uint64
sys_sysinfo(void)
{
  // TODO: 从用户态到内核态
  
  // TODO: 计算空闲内存的大小

  // TODO: 计算内存中非UNUSED的进程的数量

  // TODO: 从内核态到用户态
  return 0;
}

关于具体实现,文档提供了三个hint,我们还是按照这三个hint的步骤去做就行了:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

2.2.2 用户态与内核态交互

sysinfo needs to copy a struct sysinfo back to user space; see sys_fstat() (kernel/sysfile.c) and filestat() (kernel/file.c) for examples of how to do that using copyout().

首先依旧是获取入参,hint给了我们两个参考范例,我们可以看一看:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
可以看(猜)到,这两个文件以struct stat类型为例子,分别向我们展示了获取类型指针的方法以及将既存对象写入获取到的指针的方法,分别使用argaddrcopyout函数实现,因此我们可以依葫芦画瓢写出以下代码:

uint64
sys_sysinfo(void)
{
  uint64 addr; // 指向sysinfo结构体的指针
  struct sysinfo info;

  argaddr(0, &addr);  // 尝试从用户空间读取参数

  // TODO: 计算空闲内存的大小

  // TODO: 计算内存中非UNUSED的进程的数量

  if (copyout(myproc()->pagetable, addr, (char *)&info, sizeof(info)) < 0) // 将内核空间的sysinfo结构体复制到用户空间
    return -1;
    
  return 0;
}

2.2.3 计算空闲内存的大小

To collect the amount of free memory, add a function to kernel/kalloc.c

hint提示我们想要计算空闲内存的大小,需要在kalloc.c下添加一个函数,通过观察该文件的内容,我们不难发现,这个文件主要负责维护一个名为kmem的对象,这个名称应该是kernel memory的缩写,这个结构体内部有一个一看就是一把自旋锁的lock字段和一个一看就是负责记录空闲page的链表的freelist字段,通过综合观察我们可以知道freelist确实维护的是空闲页的数量,因此我们想要找到空闲内存的总大小,只需要遍历整个freelist,就可以找到总共空闲页的数量,而每个页有PGSIZE即4096个字节,因此我们只需要将获得的页面数乘以PGSIZE即可,于是不难写出以下代码:

// 计算空闲内存大小
uint64
kfree_mem_cnt(void)
{
  struct run *r;
  uint64 cnt = 0;

  acquire(&kmem.lock); // 由于kmem.freelist是全局变量,所以需要加锁
  r = kmem.freelist;
  while(r) {
    cnt++;
    r = r->next;
  }
  release(&kmem.lock);

  return cnt * PGSIZE;
}

值得一提的是,由于kmem是一个全局变量,属于临界资源,因此我们在访问时需要加锁。然后我们需要再kernel/defs.h下添加这个函数的声明,才能为我们所调用:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
然后在我们的sysinfo中调用它:

uint64
sys_sysinfo(void)
{
  uint64 addr; // 指向sysinfo结构体的指针
  struct sysinfo info;

  argaddr(0, &addr);  // 尝试从用户空间读取参数

  info.freemem = kfree_mem_cnt(); // 获取内存中空闲的内存大小

  // TODO: 计算内存中非UNUSED的进程的数量

  if (copyout(myproc()->pagetable, addr, (char *)&info, sizeof(info)) < 0) // 将内核空间的sysinfo结构体复制到用户空间
    return -1;

  return 0;
}

2.2.4 计算非UNUSED进程的数量

To collect the number of processes, add a function to kernel/proc.c

这个函数提醒我们写在kernel/proc.c中,这个文件我们上一个task其实已经接触过了,再来看一看吧。前文我们已经知道了每个进程的信息依赖proc结构体维护,进一步阅读不难发现,这里用一个全局数组来维护了我们的所有进程,因此,我们只需要遍历一遍这个数组,然后给其中非空闲的进程计数即可。
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
同样值得一提的是,我们翻阅struct proc的定义可以发现,注释中提示了我们,state属于临界资源,访问需要加锁:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
综合上面的内容,我们就可以比较轻松地写出如下代码:

// 计算非空闲进程的数量
uint64
get_free_proc_num(void)
{
  uint64 num = 0;
  for(struct proc* p = proc; p < &proc[NPROC]; p++){
    acquire(&p->lock);    // state是临界资源,需要加锁
    if (p->state != UNUSED)
      num++;
    release(&p->lock);
  }
  return num;
}

我们同样需要为它在defs.h中添加声明以供外部调用:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
最后我们在sysinfo的实现中调用这个函数,完成了最终步骤:

uint64
sys_sysinfo(void)
{
  uint64 addr; // 指向sysinfo结构体的指针
  struct sysinfo info;

  argaddr(0, &addr);  // 尝试从用户空间读取参数

  info.freemem = kfree_mem_cnt(); // 获取内存中空闲的内存大小

  info.nproc = get_free_proc_num(); // 获取内存中非UNUSED的进程的数量

  if (copyout(myproc()->pagetable, addr, (char *)&info, sizeof(info)) < 0) // 将内核空间的sysinfo结构体复制到用户空间
    return -1;

  return 0;
}

2.3 测试

同样的,make qemu后,按照文档中的提示运行sysinfotest,成功:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
退出终端后运行./grade-lab-syscall sysinfo本地测试,成功:
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统

3. 总测试

同样的,我们需要在根目录下创建一个time.txt,里面写上本次lab用时,比如我这个lab不算写博客花了差不多4个小时,我就写个4,然后运行make grade(跑到这一步的时候我发现gdb也叫我填一个东西在answers-syscall.txt里,答案是usertrap()),弄好后又出了个错误:

Timeout! trace children: FAIL (30.7s)

8: syscall fork -> -1
7: syscall fork -> -1
6: syscall fork -> -1
9: syscall fork -> -1
qemu-system-riscv64: terminating on signal 15 from pid 6958 (make)
MISSING ‘^ALL TESTS PASSED’
QEMU output saved to xv6.out.trace_children

6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
这个主要是由于WSL性能损失的原因,之前文档也强调过这个问题了,解决方法是自己手动改测试脚本gradelib.py,放宽时间(话说上面单独跑测试都25s过了,总的测试居然过不了,还得看运气呀):
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
然后再跑make grade
6.s081/6.1810(Fall 2022)Lab2: System calls,6.s081,c语言,操作系统
搞定!文章来源地址https://www.toymoban.com/news/detail-636183.html

到了这里,关于6.s081/6.1810(Fall 2022)Lab2: System calls的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • MIT6.S081 - Lecture3: OS Organization and System Calls

    使用操作系统的主要原因是为了实现 CPU 多进程分时复用以及内存隔离 如果没有操作系统,应用程序会直接与硬件进行交互,这时应用程序会直接使用 CPU,比如假设只有一个 CPU 核,一个应用程序在这个 CPU 核上运行,但是同时其他程序也需要运行,因为没有操作系统来帮助

    2024年04月22日
    浏览(38)
  • lab2 bomblab

    通过下面这个文件可以发现,read_line函数的结果rax放入了rdi寄存器,也就是作为phase_1函数的第一个参数,然后调用了phase_1函数 在phase_1函数中,又将0x402400放入esi寄存器,调用了strings_not_equal函数。 此时rdi寄存器存的是readline函数的结果,esi寄存器存的是一个地址,分别作为

    2024年02月15日
    浏览(34)
  • 操作系统复习 MITS6.1810 lab util 记录

    介绍:主要用来熟悉下环境以及代码结构。 See kernel/sysproc.c for the xv6 kernel code that implements the sleep system call (look for sys_sleep ), user/user.h for the C definition of sleep callable from a user program, and user/usys.S for the assembler code that jumps from user code into the kernel for sleep . 代码: 单个管道一般用于

    2024年02月15日
    浏览(33)
  • 临时表、视图与系统函数_Lab2

    理解CTE与视图的知识,掌握临时表、CTE与视图的创建与使用方法,能够根据需要创建CTE、视图,掌握视图应用技术,熟悉常用系统函数的应用方法。 1、 针对指定的表进行全文检索配置,利用全文检索检索记录。 2、 创建视图。 3、 练习常用系统函数使用方法 1、基于派生表

    2024年02月08日
    浏览(34)
  • mit s0681 lab2 Trace系统调用实现

    实验一 实现一个用户级别的程序,功能为,指定系统调用后,跟踪程序的系统调用情况 分析实验 实验目标为实现一个程序去跟踪指定程序的系统调用。因此目标有两个 实现一个程序 跟踪目标程序的系统调用 实现1,就需要在用户这边实现一个trace的相关程序,接收监控的

    2024年02月11日
    浏览(34)
  • 《深入理解计算机系统》Lab2-Bomblab

    这篇文章主要记录了我做bomblab的过程,希望能给你一些灵感 本次实验为 熟悉汇编程序 及其 调试方法 的实验。 实验内容包含2个文件:bomb(可执行文件)和bomb.c(c源文件)。 实验主题内容为: 程序运行在linux环境中。程序运行中有6个关卡(6个phase),每个phase需要用户在

    2024年02月04日
    浏览(42)
  • CS144 计算机网络 Lab2:TCP Receiver

    Lab1 中我们使用双端队列实现了字节流重组器,可以将无序到达的数据重组为有序的字节流。Lab2 将在此基础上实现 TCP Receiver,在收到报文段之后将数据写入重组器中,并回复发送方。 TCP 接收方除了将收到的数据写入重组器中外,还需要告诉发送发送方: 下一个需要的但是

    2023年04月25日
    浏览(39)
  • MIT 6.S081 Lab Three

    本文为 MIT 6.S081 2020 操作系统 实验三解析。 MIT 6.S081课程前置基础参考: 基于RISC-V搭建操作系统系列 在本实验中,您将探索页表并对其进行修改,以简化将数据从用户空间复制到内核空间的函数。 开始编码之前,请阅读xv6手册的第3章和相关文件: * kernel/memlayout.h* ,它捕获了

    2024年02月09日
    浏览(44)
  • 【MTI 6.S081 Lab】traps

    本实验阅读《深入理解计算机系统》第八章异常控制流并做shell实验将会是很有帮助的 本实验探讨了如何使用陷阱实现系统调用。您将首先使用堆栈进行热身练习,然后实现用户级陷阱处理的示例。 了解一下您在6.1910(6.004)中接触到的RISC-V程序集非常重要。在您的xv6 repo中

    2024年02月15日
    浏览(46)
  • 「实验记录」MIT 6.824 Raft Lab2C Persist

    MIT-6.824 2020 课程官网 Lab2: Raft 实验主页 simviso 精品付费翻译 MIT 6.824 课程 Paper - Raft extended version source code 的 Gitee 地址 Lab2C: Persist 的 Gitee 地址 课程官网提供的 Lab 代码下载地址,我没有访问成功,于是我从 Github 其他用户那里 clone 到干净的源码,有需要可以访问我的 Gitee 获取

    2024年02月08日
    浏览(75)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包