上一篇中我们讲到用户空间执行到调用系统中断，便完成任务，接下来就是内核空间响应系统中断，来调用对应的函数执行，本篇我们便来详细分析内核空间是如何相应系统中断，并调用相关的驱动函数执行数据收发的。
基于内核4.4.94，我们先看看内核中相应swi中断定义的位置，在arch\arm\kernel\entry-armv.S文件中定义了硬件异常向量表，其中的W(ldr) pc, __vectors_start + 0x1000便是跳转到vector_swi
我们先解释为何 __vectors_start + 0x1000便是vector_swi，在arch\arm\kernel\vmlinux.lds.S文件中，定义了.stubs节在0x1000处，而vector_swi放在了__stubs_start处，所以__vectors_start + 0x1000便是vector_swi的入口了。
下面我们看vector_swi实体的定义，在arch\arm\kernel\entry-common.S中
上面只是截取了一段，后面还有一部分，这个实体中便会将用户空间传入的参数、系统调用号、线程信息等进行处理，我们重点关注加载系统调用表这一句，
这个表定义在arch/arm/kernel/calls.S中，在这个表中我们可以看到如下定义，
从这里就可以和用户空间传入的290这个系统调用号对应了，
然后继续回到vector_swi实体，我们看这一句，便是跳转到sys_sendto函数执行了。
后面的ret_fast_syscall则是执行完sys_sendto的系统调用后，恢复寄存器，返回用户空间。
下面我们继续探索sys_sendto这个系统调用函数在内核中的定义，在net/socket.c文件中有
这是个宏定义，在include\linux\syscalls.h中有如下引用
然后经过上述展开，形态如下：
后面还有一些展开，我们不再详细展示，至此，sys_sendto函数已经初现真容，系统便从此处进入sys_sendto函数的调用，来完成相关的工作了。至此，用户态的函数通过系统调用进入内核态函数的执行就完成了。