System Call Interface

[chrisa128]

Ok, now that I have got the kernel sorted, I need to know I should implement the System Call Interface.

All my functions are contained within the kernel, do I need to put these into headers, create a library or what???

If I create a library then the functions won't be contained within the kernel but in the seperate user app, which could make the app bigger which distroys the design goal of keeping it small.

Thanks,
Chris

[Slasher]

Hi,
dedicate a certain interrupt number eg int 0x40 as the one to use to call Kernel function slike DOS' int 0x20.
then assign each function a number. then decide how you are going to get the arguments from the user. then write a higher level wrapper function(s) for them.
example
void clear_screen(char *screen,char color,int size)
{
asm {
mov ebx,screen
mov ecx,size
mov eax,color
int 0x40
}
}

[chrisa128]

I am in protected Mode, should I allocate a interrupt for each different type of function following the example of DOS or create it all in one interrupt....

[Slasher]

It is up to you to decide!
you could use 0x40 for process calls, 0x41 for files, etc
You are the DESIGNER SO YOU CAN DO IT HOW YOU LIKE, just keep record of it all.

[chrisa128]

Thanks Code Slasher,

[chrisa128]

Sorry, I neglected to ask this earlier...

But does anyone know how Windows and Linux does it, I know they have an API but how is this implemented???

Do they still use interrupts for the system call interface...

[DarylD]

I am guessing here but I think Linux uses int 0x80 for its system calls and uses an index into a call table. Its actually a very fast solution although it is quite fixed in that whatever function is at say index 10 always has to be at index 10.

Also, I think Linux keeps a symbol table with addresses of certain functions so when code is loaded, any unresolved symbols are matched against this table. This is very much a monolithic method of calling though and could be badly affected by internal kernel changes.

Not sure how windows does it.

My OS I am working on uses calls 0x80-0x84 but this works on the concept of modules, i.e. a call is made to get a handle to module "IOManager" and then this handle is used to get the call code for say call "MountVolume" and this code is then used to make calls. Although currently it is quite a bit of overhead ultimately I doubt it will really be too much of a problem as once a handle and call id have been obtained it is a simple matter of using these in future calls.

But you can do it whatever way you choose on your OS, after all it IS your os!

Daryl.

PS. I am not an expert on this!

[Pype.Clicker]

i *dislike* the way Linux and Dos/windows approach the system calls. Look at the syscall list in linux and you'll find something begging you to overload a ioctl function in /proc rather than adding a clear system call ... just pittyful.

the approach i promote is to use a resource identifier first rather than a service number. Once the resource (file handle, child process, mailbox, network socket, whatever) is found, then you will use a method_id that is specific to that resource (read=0, write=1 ...)
So you can add features to a given class of resources without bugging other developers.
Moreover, one could imagine that the method_id are left for the loader. For instance you code

Code: Select all

mov eax, console::stdout_handle
mov ebx, console::printf_methodID
int kernel::resource::method_invoke.

The loader will resolve console::stdout_handle into a stream constructor, build the system object, allocate it a resource identifier and perform code translations so that references console::stdout_handle become <stdout ID> (say it's resource #2, #1 was auto-allocated "self" process resource).

The same way, it could look up into the console::*_methodID and find it is method #5.
Finally (but less unlikely to be needed), kernel::resource::method_invoke could be resolved into 0x33 ...

So once loaded, your code will look like:

Code: Select all

mov eax, 2
mov ebx,5
int 0x33