Skip to main content

What happens from Keyboard to Kernel ?

Brief introduction to Linux kernel and shell

Users new to Linux will want to familiarise themselves with the following:
  • terminal is a program that opens a window and lets you interact with the shell
  • shell is a program that takes commands from the keyboard and gives them to the operating system to perform. Bourne-Again shell, usually referred to as bash, which is the default shell for most Linux distributions. When you first login to a server, you will be dropped into the command prompt, or shell prompt, which is where you can issue commands to the server. The shell will forward its input (usually, from your own key presses) to the running program’s stdin, and it will forward the program’s output (stdout and stderr) to its own output (usually displayed on your screen). The shell is an interface that translates commands into some low-level calls to the kernel.
  • kernel is the essential center of a computer operating system, the core that provides basic services for all other parts of the operating system. A kernel is the lowest level of easily replaceable software that interfaces with the hardware in your computer. The kernel is the part of the operating system that runs in privileged mode. It does all sorts of things like interact with hardware, do file I/O, and spawn off processes. The shell is a specific program which runs in user-space (unprivileged mode). Whenever you try to start a process with the shell, the shell has to ask the kernel to make it. In Linux, it would probably do this with the system calls fork and execve.
  • command prompt looks like this user_name@hostname:~$
* ~: is the current directory,
* $: is the prompt symbol
* # is symbol that ends the command prompt if you are logged in as root
Commands can be issued at the command prompt by specifying the name of an executable file, which can be a binary program or a script. To execute a command simply type in the name of the command and hit RETURN.
  • ls lists the files and directories and it can take different options and arguments or it can be used on its own in which case it will just list files in current directory.
In our case if we do ls -l it will print a “long listing”, which includes extra details such as permissions, ownership, file sizes, and timestamps.
And if we give it an argument like /usr (ls -l /usr)it will print long listing of files in /usr directory. But let’s just see what happens if we type only ls -l

Let’s look at the steps:

1. type ls -l into command line first

user_name@hostname:~$ ls -l

2. getline system call stores user input into a buffer

getline reads an entire line from standard input, storing it into a buffer. When user enters command into shell, getline will store the input once the newline has been processed and stored into buffer for later use.

3. break the command into tokens

The input line gets tokenized or separated into individual tokens (pieces or words) so in this case we would have ls and -l (space would be a delimiter we are separating them by)

4. check for aliases

bash alias is essentially nothing more than a keyboard shortcut, an abbreviation, a means of avoiding typing a long command sequence (example typing ll instead of ls -l could be an alias. So if there is an alias shell will replace it with a real command that alias stands for.

5. check for built-ins

Builtin commands are contained within the shell itself. When the name of a builtin command is used as the first word of a simple command, the shell executes the command directly, without invoking another program.

6. find command in PATH

If the command is not found in built-ins shell will next try to find it in the PATH environment variable. Every shell has environment list of all the environment variables. All the environment variables are stored in a form of NAME=value for PATH that looks like this: To print out the value of the PATH variable, you may use the echo command
user_name@hostname:~$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

7. build the absolute path of the command

Colons separate all the directories that can hold the command the user typed in a form of binary executable. In our case ls. The shell will use one of the system calls like access system call to check if the command is binary executable and access would actually have to take in absolute path of the command (in our case /bin/ls) and if it is it would invoke execve system call that would execute our command.

8. create a process using “fork” system call

If the program is found and the shell now has the absolute path of the command means we can call execve system call but before we do that we have to create another process using “fork” system call. So we do that so that we get the command prompt back after execve is done executing. If we don’t wait for it to complete it will exit our shell. We do that by using system call wait in the process that created a new process. New process is called child process and process that created it is called parent process.

9. execute the command using the execve system

Once we are in child process we can call our execve system call to execute our command ls -lexecve takes in as parameters our command, list of all the arguments and environment list so it would look like this:
execve(“/bin/ls”,{“ls”, “-l”}, environ)
Parent process in our case would be the shell which called ls -l command and child process would be the one that executes that command so if we want to continue inputting new commands we need the shell to print the prompt again and that will happen only after ls -l is done executing in execve and child process is done. Then the parent process will stop waiting and show us command prompt again.

10. print the prompt using PS1 and wait for new command to be entered

At the point, shell is waiting for us to enter a new command to process.

Comments

Popular posts from this blog

What Why How SDN..???????

What is SDN?   If you follow any number of news feeds or vendor accounts on Twitter, you've no doubt noticed the term "software-defined networking" or SDN popping up more and more lately. Depending on whom you believe, SDN is either the most important industry revolution since Ethernet or merely the latest marketing buzzword (the truth, of course, probably falls somewhere in between). Few people from either camp, however, take the time to explain what SDN actually means. This is chiefly because the term is so new and different parties have been stretching it to encompass varying definitions which serve their own agendas. The phrase "software-defined networking" only became popular over roughly the past eighteen months or so. So what the hell is it? Before we can appreciate the concept of SDN, we must first examine how current networks function. Each of the many processes of a router or switch can be assigned to one of three conceptual planes of operatio

NETWORKING BASICS

This article is referred from windowsnetworking.com In this article series, I will start with the absolute basics, and work toward building a functional network. In this article I will begin by discussing some of the various networking components and what they do. If you would like to read the other parts in this article series please go to: Networking Basics: Part 2 - Routers Networking Basics: Part 3 - DNS Servers Networking Basics: Part 4 - Workstations and Servers Networking Basics: Part 5 - Domain Controllers Networking Basics: Part 6 - Windows Domain Networking Basics: Part 7 - Introduction to FSMO Roles Networking Basics: Part 8 - FSMO Roles continued Networking Basics: Part 9 – Active Directory Information Networking Basics: Part 10 - Distinguished Names Networking Basics, Part 11: The Active Directory Users and Computers Console Networking Basics: Part 12 - User Account Management Networking Basics: Part 13 - Creating

Service Oriented Architecture -> Micro-Services -> Server-Less Computing

The IT landscape is ever-changing and ever-moving. We have seen it change from SOA to MicroServices and later to Serverless Computing. Now it is time to write about Kubernetes as many companies are embracing containerization and developing microservices-type applications. Containerization is getting increasingly popular. The emergence of DevOps fuelled the growth of Kubernetes. The entire process of managing infrastructure/application deployments is changing to fully automated process by using declarative configuration files. Developers are able to move the containers deployed in their laptops to staging, pre-prod and production and achieve continuous integration and continuous delivery (CI/CD). Kubernetes options like ConfigMaps allow you to decouple all configuration artifacts from an image and keep containerized apps portable by allowing you to keep all configurations in an external file. You can create your entire application as an  image . It is a snapshot of your applicatio