Kernal Related Question / OS

[Nano Adam]

If I were to take an existing kernel and would want to build on top of it, how would that be? 

 

Thanks

[Slottr]

Without any prior knowledge to OS development, extremely difficult

[Nano Adam]

14 minutes ago, Slottr said:

Without any prior knowledge to OS development, extremely difficult

So would it be better if I attempted to write my own kernel first. I am starting to understand how OS are structured and what happens at boot and all.

 

 

[Slottr]

9 minutes ago, ammar_code said:

So would it be better if I attempted to write my own kernel first. I am starting to understand how OS are structured and what happens at boot and all.

 

 

What level of programming are you at right now? 

[Nano Adam]

9 minutes ago, Slottr said:

What level of programming are you at right now? 

I am starting to learn C++. But have some knowledge in C. But know Rust pretty good. 

 

I was initially wanting to follow this tutorial:

https://os.phil-opp.com/

 

However got confused on how I would write on top of it. Like apps.

 

Thanks

 

[straight_stewie]

1 minute ago, ammar_code said:

I am starting to learn C++. But have some knowledge in C. But know Rust pretty good. 

To build a kernel you're going to need to know C pretty well, you're also going to need to know some assembly so that you can get your C programs loaded and running. Oh, and you'll need a very deep understanding of the underlying hardware that you're building for, because a kernel really isn't anything other than an interface between applications and the hardware. Which brings us to the next point:

 

5 minutes ago, ammar_code said:

However got confused on how I would write on top of it. Like apps.

If you're developing your own kernel, then you don't need to know that before you start. You'll figure that out when you're writing your kernel.

If you're following a tutorial that provides a kernel, and the tutorial doesn't cover how to actually write programs that run on that kernel, find a better tutorial.

[Nano Adam]

5 minutes ago, straight_stewie said:

To build a kernel you're going to need to know C pretty well, you're also going to need to know some assembly so that you can get your C programs loaded and running. Oh, and you'll need a very deep understanding of the underlying hardware that you're building for, because a kernel really isn't anything other than an interface between applications and the hardware. Which brings us to the next point:

 

If you're developing your own kernel, then you don't need to know that before you start. You'll figure that out when you're writing your kernel.

If you're following a tutorial that provides a kernel, and the tutorial doesn't cover how to actually write programs that run on that kernel, find a better tutorial.

Thanks! You just ended the biggest confusion my brain was undergoing. I was thinking that there was a layer between kernel and programs. Now you helped me understand that the apps run on the kernel. Correct me if I am wrong.

[straight_stewie]

23 minutes ago, ammar_code said:

Now you helped me understand that the apps run on the kernel. Correct me if I am wrong.

That is a correct understanding. Stated a third way, the function of the kernel is to arbitrate the use of system resources.

Additionally, this is about the time in people's exploration of computers where it starts to become very beneficial to study the history of computers, as that is where a lot of these answers come from.

In this case, we can go back to the late second and third generation of electronic computers, where they where starting to be used by research institutions and businesses.

When a user of a computer wanted to run a program, they submitted a punch card deck, tape reel, or other form of program to the operators. These operators then followed a system which specified which programs would be run, what order they would be run in, and what computer resources or features they had access to. The operators also served as the maintenance team for the computer. The operators additionally would guide and educate the users on the features and use of the machines, the proper way to submit jobs, would maintain use logs, dispatch error reports, and the like. In shorter words, the operators were the users interface to the computers.

In other words, the operators followed a system which controlled the users access to the machines. Hence: operating system.

[Franck]

10 hours ago, ammar_code said:

Thanks! You just ended the biggest confusion my brain was undergoing. I was thinking that there was a layer between kernel and programs. Now you helped me understand that the apps run on the kernel. Correct me if I am wrong.

Somewhat correct. Lots of program language call library functions which they make call to the kernel. It can be a long chain so it depend how you see it.

 

If you put a water bucket on a chair, and there is a rope attached to it and then you pull on the rope and the bucket will fall on the floor spilling the water. You "the app" did technically pull on the rope and the bucket felt on the floor but the rope (the library function) is the one knowing how the knot is tied in order to hold the bucket properly (make the kernel call) so that the bucket do what it is supposed to do and fall to the ground.

[straight_stewie]

4 hours ago, Franck said:

call library functions

Generally, library functions are handled by the <machine-code-generation-toolchain> in one of two ways:

1. The library function is inserted into your "code" where you make the call
   1. This might be done as a function call, i.e. it inserts the function "code" into your code
   2. This might be done by transforming the subroutine call into "in-place code"
2. The entire library is inserted into your "code"

In both cases, the end result is that the output of running the <machine-code-generation-toolchain> on your code is some executable which directly calls kernel code. To generalize that further, just because the kernel call is hidden away in a library call doesn't mean that it's not your app making the kernel call.

 

I think where you were really trying to head with this was driver calls and highly virtualized environments, where user applications invoke processes in a running user level application or system level application, which makes kernel calls for them. This is commonly done to make common but expensive processes more efficient, to aid in the arbitration of highly contested resources, to hide proprietary workings of the underlying hardware, or to make the programming environment more abstracted.

 

In which case the statement still applies: Programs use the kernel to arbitrate system resources. Programs, in the broad sense, can be either kernel level, system level, or user level. Or in other words, every bit of "code" running on a machine is a program. That's the definition of the thing.

 

But yes, you are correct in that it can be a long chain. Modern user applications, like client side Javascript applications running in a browser, can be a very long way away from the kernel. I suspect the process for that looks something like javascript --> javascript engine --> browser engine --> jit --> driver/kernel --> hardware. Still, kernel/driver calls are  in the chain, and when you write a javascript program you will cause, either directly or indirectly, wittingly or unwittingly, kernel or driver calls to be made to aid in the execution of your program.

 

For a simple operating system, the chain might look like this:

 

Just because User Level Applications might have multiple layers of abstraction themselves doesn't mean that they aren't still in the User Level Applications group.