linux系统调用的封装格式,ARM Linux系统调用的原理

ARM Linux系统调用的原理ARM Linux系统调用的原理

操作系统为在用户态运行的进程与硬件设备进行交互提供了一组接口。在应用程序和硬件之间设置一个额外层具有很多优点。首先,这使得编程更加容易,把用户从学习硬件设备的低级编程特性中解放出来。其次,这极大地提高了系统的安全性,因为内核在试图满足某个请求之前在接口级就可以检查这种请求的正确性。最后,更重要的是这些接口使得程序具有可移植性,因为只要内核所提供的一组接口相同,那么在任一内核之上就可以正确地编译和执行程序。

Unix系统通过向内核发出系统调用(system call)实现了用户态进程和硬件设备之间的大部分接口。系统调用是操作系统提供的服务,用户程序通过各种系统调用,来引用内核提供的各种服务,系统调用的执行让用户程序陷入内核,该陷入动作由swi软中断完成。

应用编程接口(API)与系统调用的不同在于,前者只是一个函数定义,说明了如何获得一个给定的服务,而后者是通过软件中断向内核发出的一个明确的请求。POSIX标准针对API,而不针对系统调用。Unix系统给程序员提供了很多API库函数。libc的标准c库所定义的一些API引用了封装例程(wrapper routine)(其唯一目的就是发布系统调用)。通常情况下,每个系统调用对应一个封装例程,而封装例程定义了应用程序使用的API。反之则不然,一个API没必要对应一个特定的系统调用。从编程者的观点看,API和系统调用之间的差别是没有关系的:唯一相关的事情就是函数名、参数类型及返回代码的含义。然而,从内核设计者的观点看,这种差别确实有关系,因为系统调用属于内核,而用户态的库函数不属于内核。

大部分封装例程返回一个整数,其值的含义依赖于相应的系统调用。返回-1通常表示内核不能满足进程的请求。系统调用处理程序的失败可能是由无效参数引起的,也可能是因为缺乏可用资源,或硬件出了问题等等。在libc库中定义的errno变量包含特定的出错码,每个出错码定义为一个常量宏。

当用户态的进程调用一个系统调用时,CPU切换到内核态并开始执行一个内核函数。因为内核实现了很多不同的系统调用,因此进程必须传递一个名为系统调用号(system call number)的参数来识别所需的系统调用。所有的系统调用核都返回一个整数值。这些返回值与封装例程返回值的约定是不同的。在内中,整数或0表示系统调用成功结束,而负数表示一个出错条件。在后一种情况下,这个值就是存放在errno变量中必须返回给应用程序的负出错码。

ARM Linux系统利用SWI指令来从用户空间进入内核空间,还是先让我们了解下这个SWI指令吧。SWI指令用于产生软件中断,从而实现从用户模式到管理模式的变换,CPSR保存到管理模式的SPSR,执行转移到SWI向量。在其他模式下也可使用SWI指令,处理器同样地切换到管理模式。指令格式如下:

SWI{cond} immed_24

其中:

immed_2424位立即数,值为从0——16777215之间的整数。

使用SWI指令时,通常使用以下两种方法进行参数传递,SWI异常处理程序可以提供相关的服务,这两种方法均是用户软件协定。

1)、指令中24位的立即数指定了用户请求的服务类型,参数通过通用寄存器传递。SWI异常处理程序要通过读取引起软件中断的SWI指令,以取得24为立即数。如:

MOV R0,#34

SWI 12

2)、指令中的24位立即数被忽略,用户请求的服务类型由寄存器R0的值决定,参数通过其他的通用寄存器传递。如:

MOV R0, #12

MOV R1, #34

SWI 0

在SWI异常处理程序中,取出SWI立即数的步骤为:首先确定引起软件中断的SWI指令是ARM指令还是Thumb指令,这可通过对SPSR访问得到;然后取得该SWI指令的地址,这可通过访问LR寄存器得到;接着读出指令,分解出立即数(低24位)。

由用户空间进入系统调用

通常情况下,我们写的用户空间应用程序都是通过封装的C lib来调用系统调用的。以0.9.30版uClibc中的open为例,来追踪一下这个封装的函数是如何一步一步的调用系统调用的。在include/fcntl.h中有定义:

#define open open64

open实际上只是open64的一个别名而已。

在libc/sysdeps/linux/common/open64.c中可以看到:

extern __typeof(open64) __libc_open64;

extern __typeof(open) __libc_open;

可见open64也只不过是__libc_open64的别名,而__libc_open64函数在同一个文件中定义:

libc_hidden_proto(__libc_open64)

int __libc_open64 (const char *file, int oflag, ...)

{

mode_t mode = 0;

if (oflag & O_CREAT)

{

va_list arg;

va_start (arg, oflag);

mode = va_arg (arg, mode_t);

va_end (arg);

}

return __libc_open(file, oflag | O_LARGEFILE, mode);

}

libc_hidden_def(__libc_open64)

最终__libc_open64又调用了__libc_open函数,这个函数在文件libc/sysdeps/linux/common/open.c中定义:

libc_hidden_proto(__libc_open)

int __libc_open(const char *file, int oflag, ...)

{

mode_t mode = 0;

if (oflag & O_CREAT) {

va_list arg;

va_start (arg, oflag);

mode = va_arg (arg, mode_t);

va_end (arg);

}

return __syscall_open(file, oflag, mode);

}

libc_hidden_def(__libc_open)

这个函数,也是仅仅根据打开标志oflag的值,来判断是否有第三个参数,若由,则获得其值。之后,便用获得的参数来调用__syscall_open(file, oflag, mode)。

__syscall_open在同一个文件中定义:

static __inline__ _syscall3(int, __syscall_open, const char *, file,

int, flags, __kernel_mode_t, mode)

在文件libc/sysdeps/linux/arm/bits/syscalls.h文件中可以看到:

#undef _syscall3

#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \

type name(type1 arg1,type2 arg2,type3 arg3) \

{ \

return (type) (INLINE_SYSCALL(name, 3, arg1, arg2, arg3)); \

}

这个宏实际上完成定义一个函数的工作,宏的第一个参数是函数的返回值类型,第二个参数是函数名,之后的参数就如同它们的参数名所表明的那样,分别是函数的参数类型及参数名。__syscall_open实际上为:

int __syscall_open (const char * file,int flags, __kernel_mode_t mode)

{

return (int) (INLINE_SYSCALL(__syscall_open, 3, file, flags, mode));

}

INLINE_SYSCALL为同一个文件中定义的宏:

#undef INLINE_SYSCALL

#define INLINE_SYSCALL(name, nr, args...)\

({ unsigned int _inline_sys_result = INTERNAL_SYSCALL (name, , nr, args);\

if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (_inline_sys_result, ), 0))\

{\

__set_errno (INTERNAL_SYSCALL_ERRNO (_inline_sys_result, ));\

_inline_sys_result = (unsigned int) -1;\

}\

(int) _inline_sys_result; })

INLINE_SYSCALL宏中最值得注意的是INTERNAL_SYSCALL,其定义如下:

#undef INTERNAL_SYSCALL

#if !defined(__thumb__)

#if defined(__ARM_EABI__)

#define INTERNAL_SYSCALL(name, err, nr, args...)\

({unsigned int __sys_result;\

{\

register int _a1 __asm__ ("r0"), _nr __asm__ ("r7");\

LOAD_ARGS_##nr (args)\

_nr = SYS_ify(name);\

__asm__ __volatile__ ("swi0x0@ syscall " #name\

: "=r" (_a1)\

: "r" (_nr) ASM_ARGS_##nr\

: "memory");\

__sys_result = _a1;\

}\

(int) __sys_result; })

#else /* defined(__ARM_EABI__) */

#define INTERNAL_SYSCALL(name, err, nr, args...)\

({ unsigned int __sys_result;\

{\

register int _a1 __asm__ ("a1");\

LOAD_ARGS_##nr (args)\

__asm__ __volatile__ ("swi%1@ syscall " #name\

: "=r" (_a1)\

: "i" (SYS_ify(name)) ASM_ARGS_##nr\

: "memory");\

__sys_result = _a1;\

}\

(int) __sys_result; })

#endif

这里也将同文件中的LOAD_ARGS宏的定义贴出来:

#define LOAD_ARGS_0()

#define ASM_ARGS_0

#define LOAD_ARGS_1(a1)\

_a1 = (int) (a1);\

LOAD_ARGS_0 ()

#define ASM_ARGS_1ASM_ARGS_0, "r" (_a1)

#define LOAD_ARGS_2(a1, a2)\

register int _a2 __asm__ ("a2") = (int) (a2);\

LOAD_ARGS_1 (a1)

#define ASM_ARGS_2ASM_ARGS_1, "r" (_a2)

#define LOAD_ARGS_3(a1, a2, a3)\

register int _a3 __asm__ ("a3") = (int) (a3);\

LOAD_ARGS_2 (a1, a2)

这几个宏用来在寄存器中加载相应的参数,参数传递的方式和普通的C函数也没有什么太大的区别,同样都是将参数列表中的参数依次放入寄存器r0、r1、r2、r3…中。

上面的SYS_ify(name)宏,是用来获得系统调用号的。

#define SYS_ify(syscall_name)(__NR_##syscall_name)

也就是__NR___syscall_open,在libc/sysdeps/linux/common/open.c中可以看到这个宏的定义:

#define __NR___syscall_open __NR_open

__NR_open在内核代码的头文件中有定义。

在这里我们忽略定义__thumb__的情况,而假设我们编译出来的库函数使用的都是ARM指令集。在上面的代码中,我们看到,根据是否定义宏__ARM_EABI__,INTERNAL_SYSCALL会被展开为两种不同的版本。关于这一点,与应用二进制接口ABI有关,不同的ABI,则会有不同的传递系统调用号的方法。对于比较新的EABI,则在r7寄存器保存系统调用号,通过swi0x0来陷入内核。否则,通过swi指令的24位立即数参数来传递系统调用号。后面还会有内核中关于这个问题的更详细的说明。

同时这两种调用方式的系统调用号也是存在这区别的,在内核的文件arch/arm/inclue/asm/unistd.h中可以看到:

#define __NR_OABI_SYSCALL_BASE0x900000

#if defined(__thumb__) || defined(__ARM_EABI__)

#define __NR_SYSCALL_BASE0

#else

#define __NR_SYSCALL_BASE__NR_OABI_SYSCALL_BASE

#endif

/*

* This file contains the system call numbers.

*/

#define __NR_restart_syscall(__NR_SYSCALL_BASE+0)

#define __NR_exit(__NR_SYSCALL_BASE+1)

#define __NR_fork(__NR_SYSCALL_BASE+2)

#define __NR_read(__NR_SYSCALL_BASE+3)

#define __NR_write(__NR_SYSCALL_BASE+4)

#define __NR_open(__NR_SYSCALL_BASE+5)

……

接下来来看操作系统对系统调用的处理。我们回到ARM Linux的异常向量表,因为当执行swi时,会从异常向量表中取例程的地址从而跳转到相应的处理程序中。在文件arch/arm/kernel/entry-armv.S中我们看到SWI异常向量:

W(ldr)pc, .LCvswi + stubs_offset

而.LCvswi在同一个文件中定义为:

.LCvswi:

.wordvector_swi

也就是最终会执行例程vector_swi来完成对系统调用的处理,接下来我们来看下在arch/arm/kernel/entry-common.S中定义的vector_swi例程(删去一些和我们的示例平台无关的代码):

.align5

ENTRY(vector_swi)

subsp, sp, #S_FRAME_SIZE

stmiasp, {r0 - r12}@ Calling r0 - r12

ARM(addr8, sp, #S_PC)

ARM(stmdbr8, {sp, lr}^)@ Calling sp, lr

mrsr8, spsr@ called from non-FIQ mode, so ok.

strlr, [sp, #S_PC]@ Save calling PC

strr8, [sp, #S_PSR]@ Save CPSR

strr0, [sp, #S_OLD_R0]@ Save OLD_R0

zero_fp

/* Get the system call number. */

#if defined(CONFIG_OABI_COMPAT)

/*

* If we have CONFIG_OABI_COMPAT then we need to look at the swi

* value to determine if it is an EABI or an old ABI call.

*/

ldrr10, [lr, #-4]@ get SWI instruction

#ifdef CONFIG_CPU_ENDIAN_BE8

//rev指令的功能是反转字中的字节序

revr10, r10@ little endian instruction

#endif

#elif defined(CONFIG_AEABI)

#else

/* Legacy ABI only. */

ldrscno, [lr, #-4]@ get SWI instruction

#endif

#ifdef CONFIG_ALIGNMENT_TRAP

ldrip, __cr_alignment

ldrip, [ip]

mcrp15, 0, ip, c1, c0@ update control register

#endif

enable_irq

// tsk是寄存器r9的别名,在arch/arm/kernel/entry-header.S中定义:// tsk.reqr9@ current thread_info

//获得线程对象的基地址。

get_thread_info tsk

// tbl是r8寄存器的别名,在arch/arm/kernel/entry-header.S中定义:

// tbl.reqr8@ syscall table pointer,

//用来存放系统调用表的指针,系统调用表在后面调用

adrtbl, sys_call_table@ load syscall table pointer

ldrip, [tsk, #TI_FLAGS]@ check for syscall tracing

#if defined(CONFIG_OABI_COMPAT)

/*

* If the swi argument is zero, this is an EABI call and we do nothing.

*

* If this is an old ABI call, get the syscall number into scno and

* get the old ABI syscall table address.

*/

bicsr10, r10, #0xff000000

eornescno, r10, #__NR_OABI_SYSCALL_BASE

ldrnetbl, =sys_oabi_call_table

#elif !defined(CONFIG_AEABI)

// scno是寄存器r7的别名

bicscno, scno, #0xff000000@ mask off SWI op-code

eorscno, scno, #__NR_SYSCALL_BASE@ check OS number

#endif

stmdbsp!, {r4, r5}@ push fifth and sixth args

tstip, #_TIF_SYSCALL_TRACE@ are we tracing syscalls?

bne__sys_trace

cmpscno, #NR_syscalls@ check upper syscall limit

adrlr, BSYM(ret_fast_syscall)@ return address

ldrccpc, [tbl, scno, lsl #2]@ call sys_* routine

addr1, sp, #S_OFF

// why也是r8寄存器的别名

2:movwhy, #0@ no longer a real syscall

cmpscno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE)

eorr0, scno, #__NR_SYSCALL_BASE@ put OS number back

bcsarm_syscall

bsys_ni_syscall@ not private func

ENDPROC(vector_swi)

上面的zero_fp是一个宏,在arch/arm/kernel/entry-header.S中定义:

.macrozero_fp

#ifdef CONFIG_FRAME_POINTER

movfp, #0

#endif

.endm

而fp位寄存器r11。

像每一个异常处理程序一样,要做的第一件事当然就是保护现场了。紧接着是获得系统调用的系统调用号。然后以系统调用号作为索引来查找系统调用表,如果系统调用号正常的话,就会调用相应的处理例程来处理,就是上面的那个ldrccpc, [tbl, scno, lsl #2]语句,然后通过例程ret_fast_syscall来返回。

在这个地方我们接着来讨论ABI的问题。现在,我们首先来看两个宏,一个是CONFIG_OABI_COMPAT意思是说与old ABI兼容,另一个是CONFIG_AEABI意思是说指定现在的方式为EABI。这两个宏可以同时配置,也可以都不配,也可以配置任何一种。我们来看一下内核是怎么处理这一问题的。我们知道,sys_call_table在内核中是个跳转表,这个表中存储的是一系列的函数指针,这些指针就是系统调用函数的指针,如(sys_open)。内核是根据一个系统调用号(对于EABI来说为系统调用表的索引)找到实际该调用内核哪个函数,然后通过运行该函数完成系统调用的。

首先,对于old ABI,内核给出的处理是为它建立一个单独的system call table,叫sys_oabi_call_table。这样,兼容方式下就会有两个system call table,以old ABI方式的系统调用会执行old_syscall_table表中的系统调用函数,EABI方式的系统调用会用sys_call_table中的函数指针。配置无外乎以下4中:第一、两个宏都配置行为就是上面说的那样。第二、只配置CONFIG_OABI_COMPAT,那么以old ABI方式调用的会用sys_oabi_call_table,以EABI方式调用的用sys_call_table,和1实质上是相同的。只是情况1更加明确。第三、只配置CONFIG_AEABI系统中不存在sys_oabi_call_table,对old ABI方式调用不兼容。只能 以EABI方式调用,用sys_call_table。

第四、两个都没有配置,系统默认会只允许old ABI方式,但是不存在old_syscall_table,最终会通过sys_call_table完成函数调用

系统会根据ABI的不同而将相应的系统调用表的基地址加载进tbl寄存器,也就是r8寄存器。接下来来看系统调用表,如前面所说的那样,有两个,同样都在文件arch/arm/kernel/entry-armv.S中:

#define ABI(native, compat) native

#ifdef CONFIG_AEABI

#define OBSOLETE(syscall) sys_ni_syscall

#else

#define OBSOLETE(syscall) syscall

#endif

.typesys_call_table, #object

ENTRY(sys_call_table)

#include "calls.S"

#undef ABI

#undef OBSOLETE

另外一个为:

#define ABI(native, compat) compat

#define OBSOLETE(syscall) syscall

.typesys_oabi_call_table, #object

ENTRY(sys_oabi_call_table)

#include "calls.S"

#undef ABI

#undef OBSOLETE

这样看来貌似两个系统调用表是完全一样的。这里预处理指令include的独特用法也挺有意思,系统调用表的内容就是整个arch/arm/kernel/calls.S文件的内容(由于太长,这里就不全部列出了):

/* 0 */CALL(sys_restart_syscall)

CALL(sys_exit)

CALL(sys_fork_wrapper)

CALL(sys_read)

CALL(sys_write)

/* 5 */CALL(sys_open)

CALL(sys_close)

……

上面的CALL()是个宏,它同样在文件arch/arm/kernel/entry-armv.S中定义:

#define CALL(x) .equ NR_syscalls,NR_syscalls+1

#include "calls.S"

#undef CALL

#define CALL(x) .long x

在定义宏CALL()的地方,我们看到calls.S已经被包含了一次,只不过在这里,不是为了建立系统调用表,而仅仅是为了获得系统的系统调用的数量,并保存在宏NR_syscalls中。在SWI向量中,我们也看到,是使用了这个宏的。

最后再罗嗦一点,如果用sys_open来搜的话,是搜不到系统调用open的定义的,系统调用函数都是用宏来定义的,比如对于open,有这样的定义:

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

fs/open.c

1066 SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, int, mode)

1067 {

1068long ret;

1069

1070if (force_o_largefile())

1071flags |= O_LARGEFILE;

1072

1073ret = do_sys_open(AT_FDCWD, filename, flags, mode);

1074/* avoid REGPARM breakage on x86: */

1075asmlinkage_protect(3, ret, filename, flags, mode);

1076return ret;

1077 }

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

继续回到vector_swi,如果系统调用号不正确,则会调用arm_syscall函数来进行处理,这个函数定义如下:

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

arch/arm/kernel/traps.c

465 #define NR(x) ((__ARM_NR_##x) - __ARM_NR_BASE)

466 asmlinkage int arm_syscall(int no, struct pt_regs *regs)

467 {

468struct thread_info *thread = current_thread_info();

469siginfo_t info;

470

471if ((no >> 16) != (__ARM_NR_BASE>> 16))

472return bad_syscall(no, regs);

473

474switch (no & 0xffff) {

475case 0: /* branch through 0 */

476info.si_signo = SIGSEGV;

477info.si_errno = 0;

478info.si_code= SEGV_MAPERR;

479info.si_addr= NULL;

480

481arm_notify_die("branch through zero", regs, &info, 0, 0);

482return 0;

483

484case NR(breakpoint): /* SWI BREAK_POINT */

485regs->ARM_pc -= thumb_mode(regs) ? 2 : 4;

486ptrace_break(current, regs);

487return regs->ARM_r0;

488

489/*

490* Flush a region from virtual address 'r0' to virtual address 'r1'

491 * _exclusive_.There is no alignment requirement on either address;

492* user space does not need to know the hardware cache layout.

493*

494* r2 contains flags.It should ALWAYS be passed as ZERO until it

495* is defined to be something else.For now we ignore it, but may

496* the fires of hell burn in your belly if you break this rule. ;)

497*

498* (at a later date, we may want to allow this call to not flush

499* various aspects of the cache.Passing '' will guarantee that

500* everything necessary gets flushed to maintain consistency in

501* the specified region).

502*/

503case NR(cacheflush):

504do_cache_op(regs->ARM_r0, regs->ARM_r1, regs->ARM_r2);

505return 0;

506

507case NR(usr26):

508if (!(elf_hwcap & HWCAP_26BIT))

509break;

510regs->ARM_cpsr &= ~MODE32_BIT;

511return regs->ARM_r0;

512

513case NR(usr32):

514if (!(elf_hwcap & HWCAP_26BIT))

515break;

516regs->ARM_cpsr |= MODE32_BIT;

517return regs->ARM_r0;

518

519case NR(set_tls):

520thread->tp_value = regs->ARM_r0;

521 #if defined(CONFIG_HAS_TLS_REG)

522asm ("mcr p15, 0, %0, c13, c0, 3" : : "r" (regs->ARM_r0) );

523 #elif !defined(CONFIG_TLS_REG_EMUL)

524/*

525* User space must never try to access this directly.

526* Expect your app to break eventually if you do so.

527* The user helper at 0xffff0fe0 must be used instead.

528* (see entry-armv.S for details)

529*/

530*((unsigned int *)0xffff0ff0) = regs->ARM_r0;

531 #endif

532return 0;

533

534 #ifdef CONFIG_NEEDS_SYSCALL_FOR_CMPXCHG

535/*

536* Atomically store r1 in *r2 if *r2 is equal to r0 for user space.

537* Return zero in r0 if *MEM was changed or non-zero if no exchange

538* happened.Also set the user C flag accordingly.

539* If access permissions have to be fixed up then non-zero is

540* returned and the operation has to be re-attempted.

541*

542* *NOTE*: This is a ghost syscall private to the kernel.Only the

543* __kuser_cmpxchg code in entry-armv.S should be aware of its

544* existence.Don't ever use this from user code.

545*/

546case NR(cmpxchg):

547for (;;) {

548extern void do_DataAbort(unsigned long addr, unsigned int fsr,

549struct pt_regs *regs);

550unsigned long val;

551unsigned long addr = regs->ARM_r2;

552struct mm_struct *mm = current->mm;

553pgd_t *pgd; pmd_t *pmd; pte_t *pte;

554spinlock_t *ptl;

555

556regs->ARM_cpsr &= ~PSR_C_BIT;

557down_read(&mm->mmap_sem);

558pgd = pgd_offset(mm, addr);

559if (!pgd_present(*pgd))

560goto bad_access;

561pmd = pmd_offset(pgd, addr);

562if (!pmd_present(*pmd))

563goto bad_access;

564pte = pte_offset_map_lock(mm, pmd, addr, &ptl);

565if (!pte_present(*pte) || !pte_dirty(*pte)) {

566pte_unmap_unlock(pte, ptl);

567goto bad_access;

568}

569val = *(unsigned long *)addr;

570val -= regs->ARM_r0;

571if (val == 0) {

572*(unsigned long *)addr = regs->ARM_r1;

573regs->ARM_cpsr |= PSR_C_BIT;

574}

575pte_unmap_unlock(pte, ptl);

576up_read(&mm->mmap_sem);

577return val;

578

579bad_access:

580up_read(&mm->mmap_sem);

581/* simulate a write access fault */

582do_DataAbort(addr, 15 + (1 << 11), regs);

583}

584 #endif

585

586default:

587/* Calls 9f00xx..9f07ff are defined to return -ENOSYS

588if not implemented, rather than raising SIGILL.This

589way the calling program can gracefully determine whether

590afeature is supported.*/

591if ((no & 0xffff) <= 0x7ff)

592return -ENOSYS;

593break;

594}

595 #ifdef CONFIG_DEBUG_USER

596/*

597* experience shows that these seem to indicate that

598* something catastrophic has happened

599*/

600if (user_debug & UDBG_SYSCALL) {

601printk("[%d] %s: arm syscall %d\n",

602task_pid_nr(current), current->comm, no);

603dump_instr("", regs);

604if (user_mode(regs)) {

605__show_regs(regs);

606c_backtrace(regs->ARM_fp, processor_mode(regs));

607}

608}

609 #endif

610info.si_signo = SIGILL;

611info.si_errno = 0;

612info.si_code = ILL_ILLTRP;

613info.si_addr= (void __user *)instruction_pointer(regs) -

614(thumb_mode(regs) ? 2 : 4);

615

616arm_notify_die("Oops - bad syscall(2)", regs, &info, no, 0);

617return 0;

618 }

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

这个函数处理所有的辨别不出来的系统调用。系统调用号正确也好不正确也好,最终都是通过ret_fast_syscall例程来返回,因为我们看到,在进入系统调用处理函数之前,先加载了符号ret_fast_syscall进lr寄存器。ret_fast_syscall定义如下:

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

arch/arm/kernel/entry-common.S

ret_fast_syscall:

UNWIND(.fnstart)

UNWIND(.cantunwind)

disable_irq@ disable interrupts

ldrr1, [tsk, #TI_FLAGS]

tstr1, #_TIF_WORK_MASK

bnefast_work_pending

/* perform architecture specific actions before user return */

arch_ret_to_user r1, lr

restore_user_regs fast = 1, offset = S_OFF

UNWIND(.fnend)

fast_work_pending:

strr0, [sp, #S_R0+S_OFF]!@ returned r0

work_pending:

tstr1, #_TIF_NEED_RESCHED

bnework_resched

tstr1, #_TIF_SIGPENDING|_TIF_NOTIFY_RESUME

beqno_work_pending

movr0, sp@ 'regs'

movr2, why@ 'syscall'

bldo_notify_resume

bret_slow_syscall@ Check work again

work_resched:

blschedule

/*

* "slow" syscall return path."why" tells us if this was a real syscall.

*/

ENTRY(ret_to_user)

ret_slow_syscall:

disable_irq@ disable interrupts

ldrr1, [tsk, #TI_FLAGS]

tstr1, #_TIF_WORK_MASK

bnework_pending

no_work_pending:

/* perform architecture specific actions before user return */

arch_ret_to_user r1, lr

restore_user_regs fast = 0, offset = 0

ENDPROC(ret_to_user)

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

对于我们的平台来说,上面的arch_ret_to_user为空。restore_user_regs宏用于恢复现场并返回,restore_user_regs宏定义如下:

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

arch/arm/kernel/entry-header.S

.macrorestore_user_regs, fast = 0, offset = 0

ldrr1, [sp, #\offset + S_PSR]@ get calling cpsr

ldrlr, [sp, #\offset + S_PC]!@ get pc

msrspsr_cxsf, r1@ save in spsr_svc

#if defined(CONFIG_CPU_32v6K)

clrex@ clear the exclusive monitor

#elif defined (CONFIG_CPU_V6)

strexr1, r2, [sp]@ clear the exclusive monitor

#endif

.if\fast

ldmdbsp, {r1 - lr}^@ get calling r1 - lr

.else

ldmdbsp, {r0 - lr}^@ get calling r0 - lr

.endif

movr0, r0@ ARMv5T and earlier require a nop

@ after ldm {}^

addsp, sp, #S_FRAME_SIZE - S_PC

movspc, lr@ return & move spsr_svc into cpsr

.endm

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

添加新的系统调用

第一、打开arch/arm/kernel/calls.S,在最后添加系统调用的函数原型的指针,例如:

CALL(sys_set_senda)

补充说明一点关于NR_syscalls的东西,这个常量表示系统调用的总的个数,在较新版本的内核中,文件arch/arm/kernel/entry-common.S中可以找到:

.equ NR_syscalls,0

#define CALL(x) .equ NR_syscalls,NR_syscalls+1

#include "calls.S"

#undef CALL

#define CALL(x) .long x

相当的巧妙,不是吗?在系统调用表中每添加一个系统调用,NR_syscalls就自动增加一。在这个地方先求出NR_syscalls,然后重新定义CALL(x)宏,这样也可以不影响文件后面系统调用表的建立。

第二、打开include/asm-arm/unistd.h,添加系统调用号的宏,感觉这步可以省略,因为这个地方定义的系统调用号主要是个C库,比如uClibc、Glibc用的。例如:

#define __NR_plan_set_senda             (__NR_SYSCALL_BASE+365)

为了向后兼容,系统调用只能增加而不能减少,这里的编号添加时,也必须按顺序来。否则会导致核心运行错误。

第三,实例化该系统调用,即编写新添加系统调用的实现例如:

SYSCALL_DEFINE1(set_senda, int,iset)

{

if(iset)

UART_PUT_CR(&at91_port[2],AT91C_US_SENDA);

else

UART_PUT_CR(&at91_port[2],AT91C_US_RSTSTA);

return 0;

}

第四、打开include/linux/syscalls.h添加函数声明

asmlinkage long sys_set_senda(int iset);

第五、在应用程序中调用该系统调用,可以参考uClibc的实现。

第六、结束。

参考文档:

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/372005.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

(延迟两秒,跳转相应页面)(返回到上一个页面并刷新)

1.setTimeout("window.location.href /moment/reason",2000);2.返回到上一个页面并刷新 self.location document.referrer;2.1常见的几种刷新方式 a.history.go(-1) 返回上一页 b.location.reload() 刷新当前页面 c.history.back() 返回上一页2.2当…

检索字符创 php

strstr()可以返回匹配的值 echo strstr("localhost", "os");返回ost echo substr_count("gggggs", "g"); 返回检索匹配字符创次数 substr_replace 字串替换函数转载于:https://www.cnblogs.com/lidepeng/p/6078064.html

android8强制将app移到sd卡,小内存手机 APP强制转移至SD卡教程

虽然近两年手机的机身内存越做越大&#xff0c;但是身边总还是有些朋友在使用几年前的手机。而面对如今海量的丰富应用&#xff0c;早年的手机中内置的存储空间已经开始捉襟见肘。虽说对于这类机型系统通常都提供了将APP转移至外置内存卡的功能&#xff0c;可是依然有一些顽固的…

在没有XML的情况下测试Spring和Hibernate

我非常热衷于Spring 3中的改进&#xff0c;这些改进最终使您能够在IDE和编译器的适当支持下从XML迁移到纯Java配置。 它并没有改变Spring是一个庞大的套件这一事实&#xff0c;并且有时发现您需要的东西可能需要一段时间。 围绕Hibernate的无XML单元测试就是这样一回事。 我知道…

Observer观察者设计模式

Observer设计模式主要包括以下两种对象: (1)被观察对象:Subject,它往往包含其他对象感兴趣的东西,上面例子中热水器中就是Subject(被监视对象); (2)观察对象:Observer,它观察着Subject,当Subject中的某件事发生后,会告知Observer,Obersver会采取相应的行动。上面例子中显示器和…

最小生成树 prime zoj1586

题意&#xff1a;在n个星球&#xff0c;每2个星球之间的联通需要依靠一个网络适配器&#xff0c;每个星球喜欢的网络适配器的价钱不同&#xff0c;先给你一个n&#xff0c;然后n个数&#xff0c;代表第i个星球喜爱的网络适配器的价钱&#xff0c;然后给出一个矩阵M[i][j]代表第…

android 书架菜单,Android入门3--做一个书架

修改名称创建项目的时候&#xff0c;APP的名字取为英文或者拼音&#xff0c;是为了简便&#xff0c;但是显示在界面上&#xff0c;我们当然希望它是中文的。taoguanstring>我们要做的很简单&#xff0c;就是在string.xml中&#xff0c;将app_name的内容修改为我们希望的名字…

第一节:整体介绍

Python版本3.5.2&#xff0c;Django版本1.10 创建一个Django工程&#xff0c;并且生成一个名字为mainsite的app django-admin.py startproject myblog python3 manage.py startapp mainsite 文件结构如下&#xff1a; x-powerxpower-CW65S:~/chen/myblog$ tree ./ ./ ├── ma…

Spring @Configuration和FactoryBean

考虑使用FactoryBean通过Spring配置文件定义缓存&#xff1a; <cache:annotation-driven /><context:component-scan base-packageorg.bk.samples.cachexml></context:component-scan><bean idcacheManager classorg.springframework.cache.support.Simpl…

cookie解决 未登录加入购物车 第一次访问弹出新手引导页面

浏览器携带cookie到服务器, 点击加入购物车-->后台检查-->是否登录(有没有sessionid) 没有登录--->secookie()返回给浏览器,把传递过来的商品id, 属性(多个属性逗号拼接),数量存起来,(序列号成字符串_不同属性用下划线拼接) 转载于:https://www.cnblogs.com/bj-tony/p…

REST + Spring Security会话问题

REST &#xff0c; 会话 ..等待。 REST应用程序中没有会话&#xff0c;对吗&#xff1f; 好吧&#xff0c;那是真的。 如果我们可以避免会议&#xff0c;我们应该这样做。 REST是无状态的 。 有关无状态性的主要问题是身份验证。 在通常的Web应用程序中&#xff0c;我们习惯于在…

程序猿果真有前端后端client吗

前端 后端 client DBA OP 程序猿有分这么细的吗?入行时候有区别. 殊途同归 吾道一以贯之, 假设作为程序猿不能领悟一贯, 则永远不清楚.转载于:https://www.cnblogs.com/blfbuaa/p/6970139.html

HarmonyOS硬件创新合作伙伴,【HarmonyOS】HarmonyOS智能硬件开发学习指南 - HDC2020

2020年9月10日&#xff0c;华为HarmonyOS 2.0版本正式官宣&#xff01;这一次&#xff0c;借助 HarmonyOS 全场景分布式系统和设备生态&#xff0c;将定义全新的硬件、交互和服务体验&#xff0c;打开焕然一新的全场景世界&#xff0c;不愧是HarmonyOS&#xff01; 那HarmonyOS…

处于RUNNABLE状态的Java线程未真正运行

最近&#xff0c;我在Java应用程序服务器安装上进行了分析/调整&#xff0c;以识别瓶颈并修复它们。 在此过程中&#xff08;调整&#xff09;&#xff0c;最常见的操作是在系统加载时检索许多线程转储。 请记住&#xff0c;重载&#xff08;在某些情况下&#xff09;可能会产生…

2.3 关系完整性

关系模型的完整性规则是对关系的某种约束条件。 也就是说关系的值随着时间变化时应该满足一些约束条件。 &#xff08;这些约束条件实际上是现实世界的要求。任何关系在任何时刻都要满足这些语义约束&#xff09; 关系模型中有三类完整性约束&#xff1a; 实体完整性 &#xff…

Android 颜色大全color.xml

使用方法&#xff1a; 将color.xml文件拷到res/values目录下后我们只需要R.xml文件名称.name名称就可以调用了(例如:R.color.red) <?xml version"1.0" encoding"utf-8"?><resources> <color name"white">#FFFFFF</color&…

鸿蒙系统华为论坛,2020中国汽车论坛上 华为三大鸿蒙车载OS系统

在今天的2020中国汽车论坛上&#xff0c;华为公布了三大鸿蒙车载OS系统&#xff0c;同时还宣布已经有大量合作伙伴基于鸿蒙OS进行开发。根据智能汽车解决方案BU总裁王军所说&#xff0c;这三大鸿蒙OS分别是——鸿蒙座舱操作系统HOS、智能驾驶操作系统AOS和智能车控操作系统VOS&…

只读ViewObject和声明性SQL模式

介绍 声明式SQL模式被认为是基于实体的视图对象的最有价值的优点之一。 在此模式下&#xff0c;根据UI中显示的属性在运行时生成VO的SQL。 例如&#xff0c;如果某个页面包含一个只有两列EmployeeId和FirstName的表&#xff0c;则查询将生成为“从Employees中选择Employee_ID&a…

android 360加固 例子,[原创]利用VirtualApp实现360加固的soHook简单例子

简单demo&#xff0c;为抛砖引玉吧&#xff01;360的加固我们先写一个最简单的so&#xff0c;带导出函数。这已经足够简单了&#xff0c;界面上打印这个值。运行起来就这样。简单的简直过分。好了&#xff0c;现在我们让360加固一下。拿下来自己签名下&#xff0c;安装好&#…

scrapy架构解析

转载于:https://www.cnblogs.com/tianboblog/p/6986695.html