OSDev.org

Hi,

I'm getting to the point where I'll be adding an elf-load, which then begs the question of how to get user-apps to interact with the kernel.

Are syscalls the only way to do this? And am I correct in assuming a syscall is just a software interrupt?

Take malloc for example: how does my libc implementation for user-land apps work such that it can actually allocate any memory?

Kindest Regards,

Jonathan

The kernel allocates pages of memory for heap, and the user malloc handles them.

System calls are the standard method to interact with the kernel, but not the only one. For example, under a message-passing system a certain place in the virtual memory of every process could be designating as containing outgoing messages and another place incoming ones. The kernel would then attempt to interpret all data it found there as messages just by looking at the address space and place replies in the proper location, all without actually "calling" anything. Most people use system calls however, because the principle of them is well researched and standardized, which perfectly suits most programmers, who don't wish to write a dissertation along with their kernel.

System calls are often implemented as software interrupts, but don't need to be. Other mechanisms, such as call gates and building system calls on top of message passing, can and are used.

Speaking of that, anyone know if other platforms have something like the x86 call gates?

Well, message passing would be nice. But how do you know when a message has arrived? Polling? Or is this another case of a software interrupt?

Message passing without system calls to pass the messages relies on polling by processes and the kernel to work. The kernel, at least, can check for one every clock tick it DOESN'T have to preempt the current process, and the process can spinlock until a reply comes in, I suppose.

I forgot one aspect of a system call: A system call will change the machine from user mode to kernel mode. This is why call GATES have to be used instead of regular call instructions. Software interrupts, in turn, can be used for system calls because ANY interrupt switches to kernel mode, or to the mode pointed to by an interrupt descriptor (on IA-32s).

I'd avoid polling. If a thread wants a message from a given other one - just have it block if the expectend message isn't there yet and wake it up upon arrival - and in the same deal delivering the message.

The other possibility to invoke kernel procedures is to use sysenter/sysexit. Has lower overhead than int xx but is said not to be supported by some cpu's.

Use abstraction/libraries to hide the actual call to kernel away. No Userland-programmer should ever need to know the pecularities of what parameter is to pushed on stack and what should be shoved into a register.

It also eases your own life.

stay safe.

According to the appropriate manuals, AMD are dropping SYSENTER and SYSEXIT (they don't work in 64-bit mode and will probably be dropped altogether in the next processor)and they advise you to use SYSCALL and SYSRET. Intel on the other hand only support SYSENTER and SYSEXIT. This leaves a bit of a compatibility problem...

Intel also supports SYSCALL and SYSRET in 64-bit mode. AMD also supports SYSENTER and SYSEXIT in 32-bit mode.

No problem as far as I can see. You might have trouble with sysenter in compatibility mode on amd64 though, but then, imo, screw intel.

Hmmm... my copy of the system programming guide (Intel) mentions SYSENTER/SYSEXIT but not SYSCALL/SYSRET. I'll have to go check for an updated version (admittedly I'm using a copy I've had around for years).

But basically, it comes down to SYSENTER/SYSEXIT in a 32-bit kernel and SYSCALL/SYSRET in a 64-bit one if you want to maintain compatibility between the processors? Can never make things easy for us can they... ::)

;D

Did the linux kernel's ABI anywhen use anything else than an interrupt gate? From the programming guides I looked at, they always issued "int $0x80", IIRC.



I can remember having read somewhere that certain ring transition techniques consume very different amounts of clock cycles on Intel and AMD CPUs. IIRC, call gates are much slower on current CPUs than interrupt gates, and I think that SYSENTER/SYSEXIT was also a problematic thing on AMD...

cheers Joe

Why are call gates slower than interrupt gates?

I'd assume that is because there are more permission checks and such with call gates as opposed to interrupt gates which just dump EIP into the kernel automatically.

Personally I prefer the idea of call gates even if they are a bit slower. Besides, there's not often a reason to call a kernel function in a tight loop...

Hi,

Call gates and interrupt gates both do almost exactly the same protection checks, except that for interrupts eflags is also pushed/popped which requires additional checks. Last time I measured them (using RDTSC on a Pentium 4), the call gates where faster.

Executing faster doesn't necessarily mean faster in practice though - a software interrupt takes 2 bytes of code while a call gate needs 7, so if you're very close to the limit of the CPUs cache then the software interrupt might save a cache miss and end up faster (this would be very rare though).

Then there's disk access times - for initialization code that is only ever run once, it's probably faster overall to use software interrupts even though they are slower (the disk transfer times would have more effect).


Cheers,

Brendan

You can have a read only page where the user can make a call to a defined address and you place there the code which is the best for the cpu! (I think windows does this)

Example:


And the same for returning from the syscall!

Windows does do that, however Brendan has previously pointed out that it adds another level of indirection which may remove any benefit of using the specific instruction to begin with (Requires a jump to the page holding the instruction, the jump can cost the clock cycles that not just using interrupts was saving).

@purevoid: You're writing your OS in OCaml, all in kernel mode, right? In this case you can just directly link against the kernel, no need to worry about gates since you have no protection rings.

Can anyone figure out the actual differences between rings 1, 2 and 3 besides that 1 and 2 are counted as supervisor mode for paging? I remember it had something to do with I/O, but for the life of me I can't find it in the IA-32 System Programming Guide.