Ceci est une ancienne révision du document !
I was observing – not participating in – a discussion on shells and realizing there is a large gap in what a shell is, where it fits in, and what the perception is thereof. This issue, I want to explain the difference between the kernel and a shell. Imagine a three-layer cake. The bottom layer is your kernel, the middle layer is your shell, and the top layer is your application layer. The kernel is all about handling hardware. When I say handling hardware, what I mean is that it allocates memory or it handles input & output, say to your disk. In other words, it manages stuff. Something needs CPU time, the kernel will schedule that. All the security and protection also happens here, within the kernel. So, when a system call happens, it is what responds to that system call. This may not be of interest to you, but to understand what a system call is, think of it this way – when you ‘call’ the system to send a packet over the network, or ‘call’ the system to read a file from disk, or call the system to do some task for us, that is a system call. I don’t know how this makes sense to a native English speaker, but to me it made no sense at first, but instead of thinking of your mother calling you to come inside, think of it more of a telephone call where you order some sand to be delivered at your home, so you can mix cement to build a wall.
The shell is an interface between the user and the system and the kernel is an interface between system calls and the actual hardware.
You may also hear people talking about ‘spaces’ – kernel space and user space. This simply groups things together into the ‘space’ where they ‘live’. VLC player and Inkscape are applications that live in user space. You, as the user, interact with them. You do not get to do things in the kernel space. For instance, the memory manager lives in the kernel space and it allocates memory for VLC or Inkscape, but you do not get to interact with it. Think of it as a lunch counter. You can order food here, the person behind the counter (the system call interface) takes your order and passes it on to the kitchen (the kernel), and out pops your food. You do not get to interact with the stove or the ingredients, but when you order a hot dog and chips, you get a hot dog and chips.
We can see how long a command spends in each by using the ‘time’ command on the command-line. Type: time ls
Look at the output, does it make sense to you?
You will see: • “real” meaning real time, • “user” meaning time spent in user space and, • “sys” meaning time spent in kernel space
Yes, I know, but go with the flow here, it is meant for n00bs.
(I found out why I had to rewrite week 47 & 48 last year…doh).
Let us do something a little more intensive to get values all around. If you have a directory with stuff in it, (no use on an empty one!), type: time md5sum *
This simply prints out the MD5 hash of the file, before printing out the file name. If you don’t know what a MD5 hash is, ask.
This can be a crude indication of where your command or program spends its time. Go ahead, try it with, say, Python (shown below) or whatever program you wish.
We used our terminal emulator (an application living in user space) to use the shell, in my case bash, to do something (make a system call).
The kernel allocated memory, handled the i/o for writing that file to disk, etc, and the ordered python program popped out, just like our hot dog example. You did not get to interact with the i/o interface, the memory manager, or the process manager, but you got your Python program. The Python program was my wall, the command I used in my shell (bash) made a system call to write a file to disk (a telephone call to order sand) – is this coming together for you yet? No? Play a *quick game of Sins of a solar empire, and come back.
That’s as short ‘n sweet as I can make it (with my brain running in a million directions, whilst I try to herd those 100 cats). If you still have trouble understanding what a shell is, and where it fits in with regards to the kernel, read that again. Just kidding, drop us a line on: misc@fullcirclemagazine.org