system libraries

[yemista]

I am just starting to design my OS and I was wondering about this before I start too far down in case it changes things. I want to design a simple OS that supports multiple processes, and I want to be able to run compiled programs on the system from a very basic command prompt. Naturally, I want to provide a library that allows an access to system calls. I was just wondering, how would this work in terms of linkage? I dont plan on anything fancy like dynamic linking, all executables will be statically built, and system calls will be implemented through interrutps. Would it be ok to have system calls end up being blank functions that just setup registers and call the sys call interrupt, and my function library would just be statically compiled into each program?

[Love4Boobies]

If I understand your question correctly (and please correct me if I don't), you're asking if you should implement system calls in the OS or not; however, you need to realise that system calls are the most basic abstraction the OS has to offer and it's one of the reasons they were invented in the first place. For instance, MS-DOS implements all services via interrupts (most notably 21H). Also, this would reduce the size of compiled programs and increase compatbility (and probably stability). You should also concern yourself with system security.

[yemista]

I will implement system calls. I dont know how much security I will build into this. It is a toy OS mainly being developed mainly for educational purposes. My question was about creating a library of system calls for user programs. Ideally, I want to be able to compile a program into a pure text file, put it on a disk, and be able to run it from my OS. The question was, what is the best way to write this library? Should all my system calls basically look like this?

int read(/*args*/) {
mov READ_NUM, %eax
mov arg1, %ebx
mov arg2, %ecx
mov arg3, %edx
int /*whatever i designate to be sys call*/
/*cleanup and return return value*/
}

And my question was, if I do this, will I be able to compile user programs that can
access my system calls just by using a simple include file? I dont plan to ever run gcc
on this system. I am designing most things myself for educational purposes.

[Love4Boobies]

Oh... well it is quite common to implement OS services via interrupts. However, instructions such as SYSENTER improve the performance quite a bit. As for how user programs will access these functions, your solution would work, of course.

[yemista]

Ok thank you, I was just afraid of what to do since I dont plan to implement dynamic linking. What do you mean by SYSENTER though?

[Brendan]

Hi,

Ok thank you, I was just afraid of what to do since I dont plan to implement dynamic linking. What do you mean by SYSENTER though?

There's different ways to implement the system call mechanism itself - software interrupts, call gates, etc. There's 2 instructions (SYSENTER and SYSCALL) which were introduced to reduce the overhead of the system call mechanism. For example, rather than using "int 0x80" to call the kernel API and the kernel using "IRET" to return to the caller, you could use "SYSENTER" to call the kernel API and "SYSEXIT" to return to the caller.

It's also possible to support different system call mechanisms at the same time - for e.g. the kernel can support a software interrupt, a call gate, SYSENTER and SYSCALL; and applications could use "int KERNEL_INT", "call KERNEL_GATE:0", SYSENTER or SYSCALL to use the same kernel API functions.

Also note that all 32-bit CPUs support software interrupts and call gates; but SYSENTER and/or SYSCALL may not be supported (depending on who made the CPU and how old it is). You can emulate SYSENTER and SYSCALL in your invalid opcode exception handler though (so that if you're running on an old CPU that doesn't support these instructions, applications that assume these instructions are supported will still work).

However "emulated SYSENTER/SYSCALL" would be the slowest option due to increased overhead. If SYSENTER/SYSCALL are supported they're the fastest option. From my tests, call gates are slightly faster than software interrupts (but for code size, call gates cost 7 bytes each where everything else only costs 2 bytes).


Cheers,

Brendan

[Love4Boobies]

What Brendan says is completely true. However, a nice compromise is to do something more Windows-like (and Windows may be using the exact mechanism I'm describing, I'm not sure, but it certainly makes sense): use user libraries to implement functions and have them make the actual system calls. This way, you can detect if SYSCALL/SYSENTER are supported and use them if so, otherwise use call gates or software interrupts, depending on your personal taste.

[Troy Martin]

I use software interrupts, they're great and easy to use in real mode!