HarmonyOS 鸿蒙Next的系统调用是如何实现的？ | 解读鸿蒙源码
HarmonyOS 鸿蒙Next的系统调用是如何实现的？ | 解读鸿蒙源码 本文将首先带您回顾“系统调用”的概念以及它的作用，然后从经典的Hello World开始，逐行代码层层分析——鸿蒙OS的系统调用是如何实现的。
9月10号 华为开发者大会（HDC）上，华为向广大开发者宣布了鸿蒙2.0系统开源，源码托管在国内源码托管平台“码云”上：
我也第一时间从码云下载了鸿蒙系统的源代码，并进行了编译和分析。当晚回看了HDC上的关于鸿蒙OS 2.0的主题演讲，个人最为好奇的是——这次开源的liteos-a内核。因为它支持了带MMU（内存管理单元）的ARM Cortex-A设备；我们知道，在带有MMU的处理器上，可以实现虚拟内存，进而实现进程之间的隔离、内核态和用户态的隔离等等这些功能。
我们先来简单回顾一下操作系统课程的一个知识点——系统调用，以及为什么会有系统调用？它的作用是什么？如果你对于这两个问题以及了然于心，可以直接跳过本段，看后面的源码分析部分。
在微控制器这样的系统资源较少的硬件系统（比如STM32、MSP430、AVR、8051）上，通常直接裸跑程序（也就是不使用任何操作系统），或者使用像FreeRTOS、Zephyr这一类的实时操作系统（RTOS）。这些实时操作系统中，应用程序和内核程序直接运行在同一个物理内存空间（因为这些设备一般没有MMU）上。而RTOS只提供了线程（或者叫任务），线程间同步、互斥等基础设施；应用程序可以直接调用内核函数（用户程序和内核程序只是逻辑上的划分，本质上并没有太大不同）；一旦有一个线程发生异常，整个系统就会重启。
而在ARM Cortex-A、x86、x86-64这样的系统资源丰富的硬件系统上，SoC或CPU芯片内部一般集成了MMU，而且CPU有特权级别状态（状态寄存器的某些位）。基于特权级别状态，可以实现部分硬件相关的操作只能在内核态进行，例如访问外设等，用户态应用程序不能访问硬件设备。在这样的系统上，系统调用是用户态应用程序调用内核功能的请求入口。通俗的说，系统调用就是在有内核态和用户态隔离的操作系统上，用户态进程访问内核态资源的一种方式。
接下来，我们一起从鸿蒙系统源码分析它在liteos-a内核上是如何实现系统调用的。鸿蒙OS使用了musl libc，应用程序和系统服务都通过musl libc封装的系统调用API接口访问内核相关功能。
下面，我们就从经典的helloworld分析整个系统调用的流程。鸿蒙系统目前官方支持了三个芯片平台，分别是Hi3516DV300（双核ARM Cortex A-7 @ 900M Hz），Hi3518EV300（单核ARM Cortex A-7 @ 900MHz 内置64MB DDR2内存）和Hi3861V100（单核RISC-V @160M Hz 内置 SRAM 和 Flash）。其中Hi3516和Hi3518是带有Cortex A7内核的芯片，鸿蒙系统在这两个平台使用的内核自然是liteos-a。根据官方指导文档，我们知道这两个平台的第一个应用程序示例都是helloworld，源码路径为：applications/sample/camera/app/src/helloworld.c，除去头部注释，代码内容为：
#include <stdio.h>
#include "los_sample.h"
int main(int argc, char **argv)
{
printf("\n************************************************\n");
printf("\n\t\tHello OHOS!\n");
printf("\n************************************************\n\n");
LOS_Sample(g_num);
return 0;
}
文件路径：third_party/musl/src/stdio/printf.c：
int printf(const char *restrict fmt, ...)
{
int ret;
va_list ap;
va_start(ap, fmt);
ret = vfprintf(stdout, fmt, ap);
va_end(ap);
return ret;
}
我们看到了，这里使用标准库的stdout作为第一个参数调用了vfprintf，我们继续向下分析third_party/musl/src/stdio/vfprintf.c文件：
int vfprintf(FILE *restrict f, const char *restrict fmt, va_list ap)
{
// 删减若干和参数 f 无关的代码行
FLOCK(f);
olderr = f->flags & F_ERR;
if (f->mode < 1) f->flags &= ~F_ERR;
if (!f->buf_size) {
saved_buf = f->buf;
f->buf = internal_buf;
f->buf_size = sizeof internal_buf;
f->wpos = f->wbase = f->wend = 0;
}
if (!f->wend && __towrite(f)) ret = -1;
else ret = printf_core(f, fmt, &ap2, nl_arg, nl_type);
if (saved_buf) {
f->write(f, 0, 0);
if (!f->wpos) ret = -1;
f->buf = saved_buf;
f->buf_size = 0;
f->wpos = f->wbase = f->wend = 0;
}
if (f->flags & F_ERR) ret = -1;
f->flags |= olderr;
FUNLOCK(f);
va_end(ap2);
return ret;
}
这里，我们继续关注三处带有参数f的调用：__towrite(f)，printf_core(f, fmt, &ap2, nl_arg, nl_type)，f->write(f, 0, 0)；
其中，__towrite的实现位于third_party/musl/src/stdio/__towrite.c（可见和系统调用无关）：
int __towrite(FILE *f)
{
f->mode |= f->mode-1;
if (f->flags & F_NOWR) {
f->flags |= F_ERR;
return EOF;
}
/* Clear read buffer (easier than summoning nasal demons) */
f->rpos = f->rend = 0;
/* Activate write through the buffer. */
f->wpos = f->wbase = f->buf;
f->wend = f->buf + f->buf_size;
return 0;
}
从内容上看，__towrite函数的作用是更新文件结构FILE的wpos、wbase、wend成员，以指向待写入实际文件的内存缓冲区域，同时将rpos、rend值为零。
printf_core的实现也位于src/stdio/vfprintf.c文件：
static int printf_core(FILE *f, const char *fmt, va_list *ap, union arg *nl_arg, int *nl_type)
{
// 删除了变量定义部分
for (;;) {
// 更新输出计数，当格式串用尽时退出循环
cnt += l;
if (!*s) break;
// 处理文本和 %% 格式说明符
for (a=s; *s && *s!='%' ; s++);
for (z=s; s[0]=='%' && s[1]=='%' ; z++, s+=2);
if (z-a > INT_MAX-cnt) goto overflow;
l = z-a;
if (f) out(f, a, l);
if (l) continue;
if (isdigit(s[1]) && s[2]=='$') {
l10n=1;
argpos = s[1]-'0';
s+=3;
} else {
argpos = -1;
s++;
}
// 读取修饰符标志
for (fl=0; (unsigned)*s-' ' < 32 && (FLAGMASK&(1U<<*s-' ')); s++)
fl |= 1U<<*s-' ';
// 读取字段宽度
if (*s=='*') {
if (isdigit(s[1]) && s[2]=='$') {
l10n=1;
nl_type[s[1]-'0'] = INT;
w = nl_arg[s[1]-'0'].i;
s+=3;
} else if (!l10n) {
w = f ? va_arg(*ap, int) : 0;
s++;
} else goto inval;
if (w<0) fl|=LEFT_ADJ, w=-w;
} else if ((w=getint(&s))<0) goto overflow;
// 读取精度
if (*s=='.' && s[1]=='*') {
if (isdigit(s[2]) && s[3]=='$') {
nl_type[s[2]-'0'] = INT;
p = nl_arg[s[2]-'0'].i;
s+=4;
} else if (!l10n) {
p = f ? va_arg(*ap, int) : 0;
s+=2;
} else goto inval;
xp = (p>=0);
} else if (*s=='.') {
s++;
p = getint(&s);
xp = 1;
} else {
p = -1;
xp = 0;
}
// 格式说明符状态机
st=0;
do {
if (OOB(*s)) goto inval;
ps=st;
st=states[st]S(*s++);
} while (st-1<STOP);
if (!st) goto inval;
// 检查参数类型的有效性（nl/normal）
if (st==NOARG) {
if (argpos>=0) goto inval;
} else {
if (argpos>=0) nl_type[argpos]=st, arg=nl_arg[argpos];
else if (f) pop_arg(&arg, st, ap);
else return 0;
}
if (!f) continue;
z = buf + sizeof(buf);
prefix = "-+ 0X0x";
pl = 0;
t = s[-1];
// 变换 ls,lc -> S,C
if (ps && (t&15)==3) t&=~32;
// 左对齐和零填充标志是互斥的
if (fl & LEFT_ADJ) fl &= ~ZERO_PAD;
switch(t) {
case 'n':
switch(ps) {
case BARE: *(int *)arg.p = cnt; break;
case LPRE: *(long *)arg.p = cnt; break;
case LLPRE: *(long long *)arg.p = cnt; break;
case HPRE: *(unsigned short *)arg.p = cnt; break;
case HHPRE: *(unsigned char *)arg.p = cnt; break;
case ZTPRE: *(size_t *)arg.p = cnt; break;
case JPRE: *(uintmax_t *)arg.p = cnt; break;
}
continue;
case 'p':
p = MAX(p, 2*sizeof(void*));
t = 'x';
fl |= ALT_FORM;
case 'x': case 'X':
a = fmt_x(arg.i, z, t&32);
if (arg.i && (fl & ALT_FORM)) prefix+=(t>>4), pl=2;
case 'o':
a = fmt_o(arg.i, z);
if ((fl&ALT_FORM) && p<z-a+1) p=z-a+1;
case 'd': case 'i':
pl=1;
if (arg.i>INTMAX_MAX) {
arg.i=-arg.i;
} else if (fl & MARK_POS) {
prefix++;
} else if (fl & PAD_POS) {
prefix+=2;
} else pl=0;
case 'u':
a = fmt_u(arg.i, z);
}
if (xp && p<0) goto overflow;
if (xp) fl &= ~ZERO_PAD;
if (!arg.i && !p) {
a=z;
break;
}
p = MAX(p, z-a + !arg.i);
break;
case 'c':
*(a=z-(p=1))=arg.i;
fl &= ~ZERO_PAD;
break;
case 'm':
if (1) a = strerror(errno);
case 's':
a = arg.p ? arg.p : "(null)";
z = a + strnlen(a, p<0 ? INT_MAX : p);
if (p<0 && *z) goto overflow;
p = z-a;
fl &= ~ZERO_PAD;
break;
case 'C':
wc[0] = arg.i;
wc[1] = 0;
arg.p = wc;
p = -1;
case 'S':
ws = arg.p;
for (i=l=0; i<p && *ws && (l=wctomb(mb, *ws++))>=0 && l<=p-i; i+=l);
if (l<0) return -1;
if (i > INT_MAX) goto overflow;
p = i;
pad(f, ' ', w, p, fl);
ws = arg.p;
for (i=0; i<0U+p && *ws && i+(l=wctomb(mb, *ws++))<=p; i+=l)
out(f, mb, l);
pad(f, ' ', w, p, fl^LEFT_ADJ);
l = w>p ? w : p;
continue;
case 'e': case 'f': case 'g': case 'a':
case 'E': case 'F': case 'G': case 'A':
if (xp && p<0) goto overflow;
l = fmt_fp(f, arg.f, w, p, fl, t);
if (l<0) goto overflow;
continue;
}
if (p < z-a) p = z-a;
if (p > INT_MAX-pl) goto overflow;
if (w < pl+p) w = pl+p;
if (w > INT_MAX-cnt) goto overflow;
pad(f, ' ', w, pl+p, fl);
out(f, prefix, pl);
pad(f, '0', w, pl+p, fl^ZERO_PAD);
pad(f, '0', p, z-a, 0);
out(f, a, z-a);
pad(f, ' ', w, pl+p, fl^LEFT_ADJ);
l = w;
}
if (f) return cnt;
if (!l10n) return 0;
for (i=1; i<=NL_ARGMAX && nl_type[i]; i++)
pop_arg(nl_arg+i, nl_type[i], ap);
for (; i<=NL_ARGMAX && !nl_type[i]; i++);
if (i<=NL_ARGMAX) goto inval;
return 1;
inval:
overflow:
从注释和代码结构可以看出，这个函数实现了格式化字符串展开的主要流程，这里又调用了out和pad两个函数，从命名猜测应该分别是向内存缓冲区写入内容和填充内容的函数，它们的实现也位于vfprintf.c中：
static void out(FILE *f, const char *s, size_t l)
{
if (!(f->flags & F_ERR)) __fwritex((void *)s, l, f);
}
static void pad(FILE *f, char c, int w, int l, int fl)
{
char pad[256];
if (fl & (LEFT_ADJ | ZERO_PAD) || l >= w) return;
l = w - l;
memset(pad, c, l>sizeof pad ? sizeof pad : l);
for (; l >= sizeof pad; l -= sizeof pad)
out(f, pad, sizeof pad);
out(f, pad, l);
}
它们又调用了__fwritex，它的实现位于third_party/musl/src/stdio/fwrite.c：
size_t __fwritex(const unsigned char *restrict s, size_t l, FILE *restrict f)
{
size_t i=0;
if (!f->wend && __towrite(f)) return 0;
if (l > f->wend - f->wpos) return f->write(f, s, l);
if (f->lbf >= 0) {
/* Match /^(.*\n|)/ */
for (i=l; i && s[i-1] != '\n'; i--);
if (i) {
size_t n = f->write(f, s, i);
if (n < i) return n;
s += i;
l -= i;
}
}
memcpy(f->wpos, s, l);
f->wpos += l;
return l+i;
}
这里又出现了vfprintf中出现的f->write(f, s, i)，下面我们就分析这个函数实际底是什么？
我们先找到它的定义prebuilts/lite/sysroot/usr/include/arm-liteos/bits/alltypes.h：
#if defined(__NEED_FILE) && !defined(__DEFINED_FILE)
typedef struct _IO_FILE FILE;
#define __DEFINED_FILE
#endif
以及third_party/musl/src/internal/stdio_impl.h：
struct _IO_FILE {
unsigned flags;
unsigned char *rpos, *rend;
int (*close)(FILE *);
unsigned char *wend, *wpos;
unsigned char *mustbezero_1;
unsigned char *wbase;
size_t (*read)(FILE *, unsigned char *, size_t);
size_t (*write)(FILE *, const unsigned char *, size_t);
off_t (*seek)(FILE *, off_t, int);
unsigned char *buf;
size_t buf_size;
FILE *prev, *next;
int fd;
int pipe_pid;
long lockcount;
int mode;
volatile int lock;
int lbf;
void *cookie;
off_t off;
char *getln_buf;
void *mustbezero_2;
unsigned char *shend;
off_t shlim, shcnt;
FILE *prev_locked, *next_locked;
struct __locale_struct *locale;
};
我们再继续寻找stdout的各个成员值是什么？
可以找到third_party/musl/src/stdio/stdout.c文件中的：
static unsigned char buf[BUFSIZ+UNGET];
hidden FILE __stdout_FILE = {
.buf = buf+UNGET,
.buf_size = sizeof buf-UNGET,
.fd = 1, // fd 为 1 和多数UNIX系统一样
.flags = F_PERM | F_NORD,
.lbf = '\n',
.write = __stdout_write, // 关注它
.seek = __stdio_seek,
.close = __stdio_close,
.lock = -1,
};
FILE *const stdout = &__stdout_FILE; // stdout 在这里
我们再继续寻找__stdout_write的实现，它在third_party/musl/src/stdio/__stdout_write.c文件中：
size_t __stdout_write(FILE *f, const unsigned char *buf, size_t len)
{
struct winsize wsz;
f->write = __stdio_write;
if (!(f->flags & F_SVB) && __syscall(SYS_ioctl, f->fd, TIOCGWINSZ, &wsz))
f->lbf = -1;
return __stdio_write(f, buf, len);
}
这段代码里调用了SYS_ioctl系统调用，但主体流程是下方的函数__stdio_write，它的实现在third_party/musl/src/stdio/__stdio_write.c文件中：
size_t __stdio_write(FILE *f, const unsigned char *buf, size_t len)
{
struct iovec iovs[2] = {
{ .iov_base = f->wbase, .iov_len = f->wpos-f->wbase },
{ .iov_base = (void *)buf, .iov_len = len }
};
struct iovec *iov = iovs;
size_t rem = iov[0].iov_len + iov[1].iov_len;
int iovcnt = 2;
ssize_t cnt;
for (;;) {
cnt = syscall(SYS_writev, f->fd, iov, iovcnt); // 看这里！
if (cnt == rem) {
f->wend = f->buf + f->buf_size;
f->wpos = f->wbase = f->buf;
return len;
}
if (cnt < 0) {
f->wpos = f->wbase = f->wend = 0;
f->flags |= F_ERR;
return iovcnt == 2 ? 0 : len-iov[0].iov_len;
}
rem -= cnt;
if (cnt > iov[0].iov_len) {
cnt -= iov[0].iov_len;
iov++; iovcnt--;
}
iov[0].iov_base = (char *)iov[0].iov_base + cnt;
iov[0].iov_len -= cnt;
}
}
至此，我们看到了printf函数最终调用到了两个系统调用SYS_ioctl和SYS_write。
在上一节中，我们看到printf最终调用到了两个长得像系统调用的函数syscall和__syscall。
系统调用宏syscall的实现
在musl代码仓（third_party/musl）下搜索：
$ find . -name '*.h' | xargs grep --color -n '\ssyscall('
可以找到third_party/musl/src/internal/syscall.h：
#define __syscall(...) __SYSCALL_DISP(__syscall,__VA_ARGS__)
#define syscall(...) __syscall_ret(__syscall(__VA_ARGS__))
这里可以看到它们两者都是宏，而syscall调用了__syscall，而__syscall又调用了__SYSCALL_DISP，它的实现也在同一个文件中：
#define __SYSCALL_NARGS_X(a,b,c,d,e,f,g,h,n,...) n
#define __SYSCALL_NARGS(...) __SYSCALL_NARGS_X(__VA_ARGS__,7,6,5,4,3,2,1,0,)
#define __SYSCALL_CONCAT_X(a,b) a#b
#define __SYSCALL_CONCAT(a,b) __SYSCALL_CONCAT_X(a,b)
#define __SYSCALL_DISP(b,...) __SYSCALL_CONCAT(b,__SYSCALL_NARGS(__VA_ARGS__))(__VA_ARGS__)
我们以__stdio_write中调用syscall处进行分析，即尝试展开syscall(SYS_writev, f->fd, iov, iovcnt)；
syscall(SYS_writev, f->fd, iov, iovcnt);
=> __syscall_ret(__syscall(SYS_writev, f->fd, iov, iovcnt)) // 展开syscall
=> __syscall_ret(__SYSCALL_DISP(__syscall, SYS_writev, f->fd, iov, iovcnt)); // 展开__syscall
先忽略最外层的 __syscall_ret，展开__SYSCALL_DISP部分：
__SYSCALL_DISP(__syscall, SYS_writev, f->fd, iov, iovcnt)
=> __SYSCALL_CONCAT(__syscall, __SYSCALL_NARGS(SYS_writev, f->fd, iov, iovcnt))(SYS_writev, f->fd, iov, iovcnt) // 展开 __SYSCALL_DISP
忽略外层的__SYSCALL_CONCAT，展开__SYSCALL_NARGS_X部分：
__SYSCALL_NARGS(SYS_writev, f->fd, iov, iovcnt)
=> __SYSCALL_NARGS_X(SYS_writev, f->fd, iov, iovcnt,7,6,5,4,3,2,1,0,) // 展开 __SYSCALL_NARGS
=> 3 // 展开 __SYSCALL_NARGS_X
// SYS_writev, f->fd, iov, iovcnt 和宏参数 a,b,c,d 对应
// 7,6,5,4 和宏参数 e,f,g,h 对应
// 3 和宏参数 n 对应
// 宏表达式的值为 n 也就是 3，
回到__SYSCALL_CONCAT展开流程，
__SYSCALL_CONCAT(__syscall, __SYSCALL_NARGS(SYS_writev, f->fd, iov, iovcnt))
=> __SYSCALL_CONCAT(__syscall, 3)
=> __SYSCALL_CONCAT_X(__syscall, 3)
=> __syscall3
再回到__SYSCALL_DISP(__syscall, SYS_writev, f->fd, iov, iovcnt)展开流程，结果应该是：
__SYSCALL_DISP(__syscall, SYS_writev, f->fd, iov, iovcnt)
=> __syscall3(SYS_writev, f->fd, iov, iovcnt)
系统调用函数__syscall3的实现
这些__syscall[1-7]的系统调用包装宏定义如下：
#ifndef __scc
#define __scc(X) ((long) (X)) // 转为long类型
typedef long syscall_arg_t;
#endif
#define __syscall1(n,a) __syscall1(n,__scc(a))
#define __syscall2(n,a,b) __syscall2(n,__scc(a),__scc(b))
#define __syscall3(n,a,b,c) __syscall3(n,__scc(a),__scc(b),__scc(c)) // <- 看这里
#define __syscall4(n,a,b,c,d) __syscall4(n,__scc(a),__scc(b),__scc(c),__scc(d))
#define __syscall5(n,a,b,c,d,e) __syscall5(n,__scc(a),__scc(b),__scc(c),__scc(d),__scc(e))
#define __syscall6(n,a,b,c,d,e,f) __syscall6(n,__scc(a),__scc(b),__scc(c),__scc(d),__scc(e),__scc(f))
#define __syscall7(n,a,b,c,d,e,f,g) __syscall7(n,__scc(a),__scc(b),__scc(c),__scc(d),__scc(e),__scc(f),__scc(g))
继续搜索发现有多出匹配，我们关注arch/arm目录下的文件，因为ARM Cortext A7是Armv7-A指令集的32位CPU（如果是Armv8-A指令集的64位CPU则对应arch/aarch64下的文件）：
static inline long __syscall3(long n, long a, long b, long c)
{
register long r7 __asm__("r7") = n;
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
register long r2 __asm__("r2") = c;
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1), "r"(r2));
}
这段代码中还有三个宏，__ASM____R7__、__asm_syscall和R7_OPERAND：
#ifdef __thumb__
#define __ASM____R7__ __asm__("r7")
#define __asm_syscall(...) do { \
__asm__ __volatile__ ( "mov %1,r7 ; mov r7,%2 ; svc 0 ; mov r7,%1" \
: "=r"(r0), "=&r"((int){0}) : __VA_ARGS__ : "memory"); \
return r0; \
} while (0)
#else // __thumb__
#define __ASM____R7__ __asm__("r7")
#define __asm_syscall(...) do { \
__asm__ __volatile__ ( "svc 0" \
: "=r"(r0) : __VA_ARGS__ : "memory"); \
return r0; \
} while (0)
#endif // __thumb__
#ifdef __thumb2__
#define R7_OPERAND "rI"(r7)
#else
#define R7_OPERAND "r"(r7)
#endif
它们有两个实现版，分别对应于编译器THUMB选项的开启和关闭。这两种选项条件下的代码流程基本一致，以下仅以未开启THUMB选项为例进行分析。这两个宏展开后的__syscall3函数内容为：
static inline long __syscall3(long n, long a, long b, long c)
{
register long r7 __asm__("r7") = n; // 系统调用号
register long r0 __asm__("r0") = a; // 参数0
register long r1 __asm__("r1") = b; // 参数1
register long r2 __asm__("r2") = c; // 参数2
do { \
__asm__ __volatile__ ( "svc 0" \
: "=r"(r0) : "r"(r7), "0"(r0), "r"(r1), "r"(r2) : "memory"); \
return r0; \
} while (0);
}
这里最后的一个内嵌汇编比较复杂，它符合如下格式（具体细节可以查阅gcc内嵌汇编文档的扩展汇编说明）：
asm asm-qualifiers
AssemblerTemplate
OutputOperands
[ : InputOperands
[ : Clobbers ]]
汇编模板为："svc 0", 输出参数部分为："=r"(r0)，输出寄存器为r0 输入参数部分为："r"(r7), "0"(r0), "r"(r1), "r"(r2)，输入寄存器为r7，r0，r1，r2，("0"的含义是，这个输入寄存器必须和输出寄存器第0个位置一样) Clobber部分为："memory"
这里我们只需要记住：系统调用号存放在r7寄存器，参数存放在r0,r1,r2，返回值最终会存放在r0中；
SVC指令，ARM Cortex A7手册 的解释为：
The SVC instruction causes a Supervisor Call exception. This provides a mechanism for unprivileged software to make a call to the operating system, or other system component that is accessible only at PL1.
翻译过来就是说
SVC指令会触发一个“特权调用”异常。这为非特权软件调用操作系统或其他只能在PL1级别访问的系统组件提供了一种机制。
详细的指令说明在
到这里，我们分析了鸿蒙系统上应用程序如何进入内核态，主要分析的是musl libc的实现。
既然SVC能够触发一个异常，那么我们就要看看liteos-a内核是如何处理这个异常的。
ARM Cortex A7中断向量表
在ARM架构参考手册中，可以找到中断向量表的说明：
可以看到SVC中断向量的便宜地址是0x08，我们可以在kernel/liteos_a/arch/arm/arm/src/startup目录的reset_vector_mp.S文件和reset_vector_up.S文件中找到相关汇编代码：
__exception_handlers:
/*
*Assumption*: ROM code has these vectors at the hardware reset address.
*A simple jump removes any address-space dependencies [i.e. safer]
*/
b reset_vector
b _osExceptUndefInstrHdl
b _osExceptSwiHdl
b _osExceptPrefetchAbortHdl
b _osExceptDataAbortHdl
b _osExceptAddrAbortHdl
b OsIrqHandler
b _osExceptFiqHdl
PS: kernel/liteos_a/arch/arm/arm/src/startup目录有两个文件reset_vector_mp.S文件和reset_vector_up.S文件分别对应多核和单核编译选项：
ifeq ($(LOSCFG_KERNEL_SMP), y)
LOCAL_SRCS += src/startup/reset_vector_mp.S
else
LOCAL_SRCS += src/startup/reset_vector_up.S
endif
SVC中断处理函数
上面的汇编代码中可以看到，_osExceptSwiHdl函数就是SVC异常处理函数，具体实现在kernel/liteos_a/arch/arm/arm/src/los_hw_exc.S文件中：
@ Description: Software interrupt exception handler
_osExceptSwiHdl:
SUB SP, SP, #(4 * 16) @ 栈增长
STMIA SP, {R0-R12} @ 保存R0-R12寄存器到栈上
MRS R3, SPSR @ 移动SPSR寄存器的值到R3
MOV R4, LR
AND R1, R3, #CPSR_MASK_MODE @ Interrupted mode
CMP R1, #CPSR_USER_MODE @ User mode
BNE OsKernelSVCHandler @ Branch if not user mode
@ we enter from user mode, we need get the values of USER mode r13(sp) and r14(lr).
@ stmia with ^ will return the user mode registers (provided that r15 is not in the register list).
MOV R0, SP
STMFD SP!, {R3} @ Save the CPSR
ADD R3, SP, #(4 * 17) @ Offset to pc/cpsr storage
STMFD R3!, {R4} @ Save the CPSR and r15(pc)
STMFD R3, {R13, R14}^ @ Save user mode r13(sp) and r14(lr)
SUB SP, SP, #4
PUSH_FPU_REGS R1
MOV FP, #0 @ Init frame pointer
CPSIE I @ Interrupt Enable
BLX OsArmA32SyscallHandle
CPSID I @ Interrupt Disable
POP_FPU_REGS R1
ADD SP, SP,#4
LDMFD SP!, {R3} @ Fetch the return SPSR
MSR SPSR_cxsf, R3 @ Set the return mode SPSR
@ we are leaving to user mode, we need to restore the values of USER mode r13(sp) and r14(lr).
@ ldmia with ^ will return the user mode registers (provided that r15 is not in the register list)
LDMFD SP!, {R0-R12}
LDMFD SP, {R13, R14}^ @ Restore user mode R13/R14
ADD SP, SP, #(2 * 4)
LDMFD SP!, {PC}^ @ Return to user
这段代码的注释较为清楚，可以看到，内核模式会继续调用OsKernelSVCHandler，用户模式会继续调用OsArmA32SyscallHandle函数；
OsArmA32SyscallHandle函数
我们这里分析的流程是从用户模式进入的，所以调用的是OsArmA32SyscallHandle，它的实现位于kernel/liteos_a/syscall/los_syscall.c文件：
/* The SYSCALL ID is in R7 on entry. Parameters follow in R0..R6 */
LITE_OS_SEC_TEXT UINT32 *OsArmA32SyscallHandle(UINT32 *regs)
{
UINT32 ret;
UINT8 nArgs;
UINTPTR handle;
UINT32 cmd = regs[REG_R7];
if (cmd >= SYS_CALL_NUM) {
PRINT_ERR("Syscall ID: error %d !!!\n", cmd);
return regs;
}
if (cmd == __NR_sigreturn) {
OsRestorSignalContext(regs);
return regs;
}
handle = g_syscallHandle[cmd]; // 得到实际系统调用处理函数
nArgs = g_syscallNArgs[cmd / NARG_PER_BYTE]; /* 4bit per nargs */
nArgs = (cmd & 1) ? (nArgs >> NARG_BITS) : (nArgs & NARG_MASK);
if ((handle == 0) || (nArgs > ARG_NUM_7)) {
PRINT_ERR("Unsupport syscall ID: %d nArgs: %d\n", cmd, nArgs);
regs[REG_R0] = -ENOSYS;
return regs;
}
switch (nArgs) { // 以下各个case是实际函数调用
case ARG_NUM_0:
case ARG_NUM_1:
ret =更多关于HarmonyOS 鸿蒙Next的系统调用是如何实现的？ | 解读鸿蒙源码的实战教程也可以访问 https://www.itying.com/category-93-b0.html
HarmonyOS鸿蒙Next的系统调用实现主要基于微内核架构，系统调用通过轻量级的进程间通信（IPC）机制完成。鸿蒙Next的微内核设计将核心功能模块化，系统调用通过内核提供的接口与这些模块进行交互。具体实现上，系统调用通过用户态与内核态的切换，将请求传递给内核，内核再通过IPC机制将请求分发到相应的服务模块进行处理。
鸿蒙Next的系统调用接口设计遵循了简洁高效的原则，减少了不必要的上下文切换和资源开销。系统调用的实现依赖于鸿蒙的分布式能力，支持跨设备的调用和资源共享。此外，鸿蒙Next还引入了安全机制，确保系统调用的安全性和隔离性，防止恶意操作对系统造成影响。
在源码层面，系统调用的实现涉及内核的调度、IPC机制、以及各服务模块的协同工作。鸿蒙Next的源码中，系统调用的相关代码主要集中在内核模块和服务管理模块中，通过定义清晰的接口和协议，确保系统调用的高效执行。
更多关于HarmonyOS 鸿蒙Next的系统调用是如何实现的？ | 解读鸿蒙源码的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
