OSDev.org

Posted: **Tue May 15, 2007 6:52 am**

Colonel Kernel wrote:@JJeronimo:
If I understand you correctly, then I think what you're proposing resembles an Exokernel.

No! Exokernel design would be orthogonal to this. Just like what happens with exo-microkernels and exo-monolithic kernels. This design could force, or not, abstractions to the applications... and they would not be able to bypass the user-mode kernel (by directly calling the kernel-mode layer), because this would allow they to make undesirable things...

You could make the "user-mode kernel layer" API very general and then create a subsystem-layer, that would be, kindof, a libOS. But this "user-mode kernel layer" is *not* a libOS... It's a part of the kernel that runs in user-mode (unprivileged mode, I mean), but in everything else it's just like a normal monolithic or micro kernel, in the sense that it's present in every address space and in the same range, and implements OS-critical jobs (task management and things alike).

JJ

Posted: **Wed May 16, 2007 1:31 am**

I found a link that explains how the Windows OS does the privilege switches. It uses INT 0x2E to switch to the kernel code in NTDLL.dll. So basically it is using an interrupt.

I tried to trace some of the API calls in Delphi and saw that first the CALL instruction will change the EIP to a long jump using the jump table. The CS:EIP will then be changed to where the INT will occur for the privilege level. However, as for my own OS, I really am not sure where to start. I guess I am going to have to read a lot about this.

Posted: **Wed May 16, 2007 6:34 am**

Looks like you're right, but:

Code: Select all

7C90EB8B >/$ 8BD4           MOV EDX,ESP
7C90EB8D  |. 0F34           SYSENTER
7C90EB8F  |. 90             NOP
7C90EB90  |. 90             NOP
7C90EB91  |. 90             NOP
7C90EB92  |. 90             NOP
7C90EB93  |. 90             NOP
7C90EB94 >\$ C3             RETN

This was the code of KiFastSystemCall.

Code: Select all

7C90EBA5 >/$ 8D5424 08      LEA EDX,DWORD PTR SS:[ESP+8]
7C90EBA9  |. CD 2E          INT 2E
7C90EBAB  \. C3             RETN

This was the code of KiIntSystemCall

However, I'm sure Windows tries to figure out, whether you have the SYS* instructions. If not, it tries to call KiIntSystemCall, otherwise KiFastSystemCall. That's my theory

Posted: **Wed May 16, 2007 7:13 am**

No, because a "kernel script" could perform many operations on a single call.
But access to the data structures could be done by directly reading from the read-only pages.

Oh - So you are trying to bundle more I/O information into a single call. I would imagine that if that was of a ultimate concern you could do something like:

struct tKernelCall{
unsigned int call_number;
unsigned int arguments[4];
unsigned int return_value;
};

Then when making system calls have them do something like:

Code: Select all

unsigned int g_ulib_kcall_index = 0;
struct tKernelCall *g_ulib_kcall;
void _a_system_call(unsigned int fd, unsigned int flags){
     g_ulib_kcall[g_ulib_kcall_index].call_number = THIS_FUNCTION_SYSCALL_NUMBER;
     g_ulib_kcall[g_ulib_kcall_index].arguments[0] = fd;
     g_ulib_kcall[g_ulib_kcall_index].arguments[1] = flags;
     g_ulib_kcall[g_ulib_kcall_index].return_value = 0;
     ++g_ulib_kcall_index;
}

.
It does seem like you could treat it exactly like a asynchronous I/O system although it is not but rather a buffer of I/O commands and then a commit button. Is this what you mean?

Posted: **Wed May 16, 2007 8:34 am**

INF1n1t wrote:However, I'm sure Windows tries to figure out, whether you have the SYS* instructions. If not, it tries to call KiIntSystemCall, otherwise KiFastSystemCall. That's my theory

I believe I explained that already:

Colonel Kernel wrote:The real system calls are invoked via stubs in ntdll.dll. The stubs actually jump to processor-specific code that is mapped into each process' address space (to avoid conditional processor-detection logic on each system call). I believe XP and Vista use sysenter/sysexit or syscall/sysret for newer processors, and they probably still use the int instruction for older processors (if they even support processors that old).

Keep up next time.

Posted: **Thu May 17, 2007 3:04 pm**

Colonel Kernel wrote:
INF1n1t wrote:However, I'm sure Windows tries to figure out, whether you have the SYS* instructions. If not, it tries to call KiIntSystemCall, otherwise KiFastSystemCall. That's my theory
I believe I explained that already:

Colonel Kernel wrote:The real system calls are invoked via stubs in ntdll.dll. The stubs actually jump to processor-specific code that is mapped into each process' address space (to avoid conditional processor-detection logic on each system call). I believe XP and Vista use sysenter/sysexit or syscall/sysret for newer processors, and they probably still use the int instruction for older processors (if they even support processors that old).
Keep up next time.

Sorry, I didn't read the other posts on the topic

Looks like they support processors without SYS* instructions

Posted: **Mon Jun 18, 2007 6:09 pm**

XCHG wrote:I found a link that explains how the Windows OS does the privilege switches. It uses INT 0x2E to switch to the kernel code in NTDLL.dll. So basically it is using an interrupt.

Very well... Now, I'm reading some files from the ReactOS source code and that's right: it's both int 2Eh and fast system calls...
http://svn.reactos.org/viewcvs/reactos/ ... iew=markup

JJ

OSDev.org

System calls in Windows Operating System