Application Binary Interface

epickh commented

2023-03-15 20:15:49 +00:00

Owner

The binary interface with interrupts, etc.. The interface which modules have to use for being accepted into the kernel privilege part.

epickh added this to the General Planning project 2023-03-15 20:15:49 +00:00

epickh commented

2023-03-15 20:31:52 +00:00

Author

Owner

Generally, syscalls can be grouped into 5 categories:

Files
I don't think I need to explain this. ^^
Memory
Alloc'ing of pages, free'ing pages, labelling regions of memory as belonging to a (theoretical, virtual) file, giving other processes the rights to use a region of memory. That's basically it.
Safety
For telling how to handle invalid operations, there must be some syscalls (or another way to tell the ABI what to do). Those then tell the kernel what to do if, for example, invalid memory got used, but there should also be a way in some part of the ABI for finding out if a process (or a thread in specific) is allowed to do some memory action.
Code Management
The code management lets the user application start executables from a stream (like a file, but not necessarily a typical file) and makes it possible to link to shared objects.
Module Interface
The part in which the calls for external modules are. I'd make the external modules ask for a lot of things, even though that'd damage the performance.

Question 1: Should the Module Interface be inside the Code Management? I'd say no, even though modules in my understanding would be shared objects. My reason for that opinion is that the module interfaces have a big definition and special syscalls for each type of module, so subdividing it would be great.

Question 2: Is there a solution for the problem in the Module Interface; that modules cannot damage too much but are still of well performance? I mean, a Hybrid Kernel approach would be great for that, having some modules inside the kernel and some outside, for example as SOs.

Question 3: What could be the syscalls of each category? I will write some into here, but others' responses would be appreciated.

Generally, *syscalls* can be grouped into 5 categories: 1) Files I don't think I need to explain this. ^^ 2) Memory Alloc'ing of pages, free'ing pages, labelling regions of memory as belonging to a (theoretical, virtual) file, giving other processes the rights to use a region of memory. That's basically it. 3) Safety For telling how to handle invalid operations, there must be some syscalls (or another way to tell the ABI what to do). Those then tell the kernel what to do if, for example, invalid memory got used, but there should also be a way in some part of the ABI for finding out if a process (or a thread in specific) is allowed to do some memory action. 4) Code Management The code management lets the user application start executables from a stream (like a file, but not necessarily a *typical* file) and makes it possible to link to shared objects. 5) Module Interface The part in which the calls for external modules are. I'd make the external modules ask for a lot of things, even though that'd damage the performance. Question 1: Should the Module Interface be inside the Code Management? I'd say no, even though modules in my understanding would be shared objects. My reason for that opinion is that the module interfaces have a big definition and special syscalls for each type of module, so subdividing it would be great. Question 2: Is there a solution for the problem in the Module Interface; that modules cannot damage too much but are still of well performance? I mean, a Hybrid Kernel approach would be great for that, having some modules inside the kernel and some outside, for example as SOs. Question 3: What could be the syscalls of each category? I will write some into here, but others' responses would be appreciated.

epickh commented

2023-03-15 20:33:34 +00:00

Author

Owner

I'd like to go for a memory-based approach on the ABI, meaning that many things can be done by writing to a specific memory address and possibly, but not necessarily, updating the buffer. For crash handlers, the pointer to the handler function and the userdata which is required would be written into a specific virtual address which is always the same at program entry (and also after that). Some things should be real syscalls, though.

I'd like to go for a memory-based approach on the ABI, meaning that many things can be done by writing to a specific memory address and possibly, but not necessarily, updating the buffer. For crash handlers, the pointer to the handler function and the userdata which is required would be written into a specific virtual address which is always the same at program entry (and also after that). Some things should be *real* syscalls, though.

epickh added the due date 2023-04-01

2023-03-15 20:35:28 +00:00

antifallobst was assigned by epickh

2023-03-15 20:35:39 +00:00

epickh self-assigned this 2023-03-15 20:35:39 +00:00

epickh added the

help wanted

label 2023-03-15 20:35:55 +00:00

Application Binary Interface #2