來到了0xffffe400這里的一段代碼，這里就是內核為我們映射的系統調用入口代碼。在gdb中，我們可以直接反匯編來查看這里的代碼
(gdb) disassemble 0xffffe400 0xffffe414
Dump of assembler 買粉絲de from 0xffffe400 to 0xffffe414:0xffffe400: push %ecx
0xffffe401: push %edx
0xffffe402: push %ebp
0xffffe403: mov %esp,%ebp
0xffffe405: sysenter
0xffffe407: nop
0xffffe408: nop
0xffffe409: nop
0xffffe40a: nop
0xffffe40b: nop
0xffffe40c: nop
0xffffe40d: nop
0xffffe40e: jmp 0xffffe403
0xffffe410: pop %ebp
0xffffe411: pop %edx
0xffffe412: pop %ecx
0xffffe413: ret
End of assembler mp.
這段代碼正是arch/i386/kernel/vsyscall- sysenter.S文件中的代碼。其中，在sysenter之前的是入口代碼，在0xffffe410開始的是內核返回處理代碼（后面提到的 SYSENTER_RETURN即指向這里）。在入口代碼中，首先是保存當前的ecx，edx（由于sysexit指令需要使用這兩個寄存器）以及 ebp。然后調用sysenter指令，跳轉到內核Ring 0代碼，也就是sysenter_entry入口處。
內核中的處理和返回
sysenter_entry整個的實現可以參見arch/i386/kernel/entry.S。內核處理SYSENTER的代碼和處理INT的代碼不太一樣。通過sysenter指令進入Ring 0之后，由于當前的ESP并非指向正確的內核棧，而是當前CPU的TSS結構中的一個緩沖區（參見上文），所以首先要解決的是修復ESP，幸運的是，TSS結構中ESP0成員本身就保存有Ring 0狀態的ESP值，所以在這里將TSS結構中ESP0的值賦予ESP寄存器。將ESP恢復成指向正確的堆棧之后，由于SYSENTER不是通過調用門進入Ring 0，所以在堆棧中的上下文和使用INT指令的不一樣，INT指令進入Ring 0后棧中會保存如下的值。
低地址
返回用戶態的EIP
用戶態的CS
用戶態的EFLAGS
用戶態的ESP
用戶態的SS（和DS相同）
高地址
因此，為了簡化和重用代碼，內核會用pushl指令往棧中放入上述各值，值得注意的是，內核在棧中放入的相對應用戶態EIP的值，是一個代碼標簽 SYSENTER_RETURN，在vsyscall-sysenter.S可以看到，它就在sysenter指令的后面（在它們之間，有一段NOP，是內核返回出錯時的處理代碼）。接下來，處理系統調用的代碼就和中斷方式的處理代碼一模一樣了，內核保存所有的寄存器，然后系統調用表找到對應系統調用的入口，完成調用。最后，內核從棧中取出前面存入的用戶態的EIP和ESP，存入edx和ecx寄存器，調用SYSEXIT指令返回用戶態。返回用戶態之后，從棧中取出ESP，edx，ecx，最終返回glibc庫。
其它操作系統以及其它硬件平臺的支持
值得一提的是，從 Windows XP 開始，Windows 的系統調用方式也從軟中斷 int 0x2e 轉換到采用 sysenter 方式，由于完全不再支持 int 方式，因此 Windows XP 的對 CPU 的最低配置要求是 PentiumII 300MHz。在其它的操作系統例如 *BSD 系列，目前并沒有提供對 sysenter 指令的支持。
在 CPU 方面，AMD 的 CPU 支持一套與之對應的指令 SYSCALL/SYSRET。在純 32 位的 AMD CPU 上，還沒有支持 sysenter 指令，而在 AMD 推出的 AMD64 系列 CPU 上，處于某些模式的情況下，CPU 能夠支持 sysenter/sysexit 指令。在 Linux 內核針對 AMD64 架構的代碼中，采用的還是 SYSCALL/SYSRET 指令。至于這兩種指令最終誰將成為標準，目前還無法得出結論。
未來
我們將 Intel 的 sysenter/sysexit 指令，AMD 的 SYSCALL/SYSRET 指令統稱為"快速系統調用指令"。"快速系統調用指令"比起中斷指令來說，其消耗時間必然會少一些，但是隨著 CPU 設計的發展，將來應該不會再出現類似 Intel Pentium4 這樣懸殊的差距。而"快速系統調用指令"比起中斷方式的系統調用方式，還存在一定局限，例如無法在一個系統調用處理過程中再通過"快速系統調用指令"調用別的系統調用。因此，并不一定每個系統調用都需要通過"快速系統調用指令"來實現。比如，對于復雜的系統調用例如 fork，兩種系統調用方式的時間差和系統調用本身運行消耗的時間來比，可以忽略不計，此處采取"快速系統調用指令"方式沒有什么必要。而真正應該使用" 快速系統調用指令"方式的，是那些本身運行時間很短，對時間精確性要求高的系統調用，例如 getuid、gettimeofday 等等。因此，采取靈活的手段，針對不同的系統調用采取不同的方式，才能得到最優化的性能和實現最完美的功能。
[1] VxWorks Optimized for Intel Architecture, Hdei Nunoe, Wind River, Member of Technical Staff Leo Samson, Wind River, Technical Marketing Engineer David Hillyard, Intel Corporation, Mgr., Platform Architect
[2] Kernel Entry / Kernel Exit , Marcus Voelp & University Karlsruhe
[3] Dave Jones' blog, 買粉絲://diary.買粉絲demonkey.org.uk/index.php?month=12&year=2002
[4] Linux 內核源碼 v2.6.0 買粉絲://買粉絲.kernel.org/ [Linus Torvalds，2004]
[5] GNU C Library glibc 2.3.3 源碼 買粉絲://買粉絲.gnu.org/software/libc/libc.買粉絲
Linux Kernel Mailing List 中對系統調用方式的討論： [5] Linux Kernel Mailing List, "Intel P6 vs P7 system call performance" 買粉絲://買粉絲.ussg.iu.e/hypermail/linux/kernel/0212.1/index.買粉絲#1286 買粉絲://買粉絲.ussg.iu.e/hypermail/linux/kernel/0212.3/index.買粉絲#54
Linux 內核首次引入對 sysenter/sysexit 指令的支持： [6] Linux Kernel Mailing List, "Add "sysenter" support on x86, and a "vsyscall" page." 買粉絲://lwn.買粉絲/Articles/18414/