Page 1 of 1

User API - MEganetOS3

Posted: Tue Apr 01, 2008 7:11 am
by Kieran
How should I implement an API system for user applications?

The way I think I am going to do it is to have an Interrupt handler, which will pass user applications a pointer to the SYS subfunction, which will contain common functions.

Is this a good idea?

Re: User API - MEganetOS3

Posted: Tue Apr 01, 2008 7:17 am
by cyr1x
Kieran wrote: Is this a good idea?
I think not because they can't be protected by ring 0 anymore, as they must be in ring 3 then. You should stick with the general handling of syscalls.
"mov" the arguments into the registers and then call an interrupt which handles the syscall.

Re: User API - MEganetOS3

Posted: Tue Apr 01, 2008 7:43 am
by mrvn
Kieran wrote:How should I implement an API system for user applications?

The way I think I am going to do it is to have an Interrupt handler, which will pass user applications a pointer to the SYS subfunction, which will contain common functions.

Is this a good idea?
Look at how linux does it in recent 2.6.x kernels:

The kernel has a small segment of memory (one page) that contains trampoline functions that invoke syscalls. When exec() is called that page is mapped into the address space of the program at the end of the address space and the address is passed as additional argument to the elf startup code (so the address can be changed between kernels).

Code: Select all

% cat /proc/self/maps
00400000-00405000 r-xp 00000000 08:01 63514                              /bin/cat
00504000-00505000 rw-p 00004000 08:01 63514                              /bin/cat
00505000-00526000 rw-p 00505000 00:00 0                                  [heap]
2b1dc59d6000-2b1dc59ed000 r-xp 00000000 08:01 100507                     /lib/ld-2.3.6.so
2b1dc59ed000-2b1dc59ef000 rw-p 2b1dc59ed000 00:00 0 
2b1dc5aec000-2b1dc5aee000 rw-p 00016000 08:01 100507                     /lib/ld-2.3.6.so
2b1dc5aee000-2b1dc5c0f000 r-xp 00000000 08:01 100513                     /lib/libc-2.3.6.so
2b1dc5c0f000-2b1dc5d0e000 ---p 00121000 08:01 100513                     /lib/libc-2.3.6.so
2b1dc5d0e000-2b1dc5d23000 r--p 00120000 08:01 100513                     /lib/libc-2.3.6.so
2b1dc5d23000-2b1dc5d26000 rw-p 00135000 08:01 100513                     /lib/libc-2.3.6.so
2b1dc5d26000-2b1dc5d2b000 rw-p 2b1dc5d26000 00:00 0 
7fffe50bf000-7fffe50d4000 rw-p 7fffe50bf000 00:00 0                      [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vdso]
The vdso is said segment of trampoline functions.

Depending on the cpu type and capabilities the code in that page will differ. On i486 it will use int 80 for a syscall. On modern amd cpus it uses the sysenter opcode and on modern intel cpus the syscall (or other way around). That way the kernel can use the fastest method for syscalls while the user space application has only a single ABI that it uses.


In the case of linux it only provides a verry specific common function, one that makes an actual syscall. But nothing stops you from providing strlen(), strcpy(), memcpy(), malloc(), free() and any number of functions.

MfG
Mrvn