Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
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).
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.
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
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
I think, I have problems with Bochs. The biggest one: Bochs hates me!
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:
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?
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.
Top three reasons why my OS project died:
Too much overtime at work
Got married
My brain got stuck in an infinite loop while trying to design the memory manager
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
I think, I have problems with Bochs. The biggest one: Bochs hates me!
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.
