Esteve Personal Blog

As writing the guidelines will keep changing, this being the reason of the existence of the category project guidelines .

I’ve changed the chapter named Concepts and Design for Concepts and background, this chapter intends to give a brief explanation of what a kernel is, a brief history on kernel development and a kernel classification with some illustrative examples of real kernels.

This is how I will be structuring next chapters:

• Project Scope: Replaces Introduction, and gives a brief scope of the project
• Concepts and Background: Basic concepts, some history and kernel classification with illustrative examples.
• Target Architecture: The whole project is based on X86, here I will discuss the basics of this architecture, introducing some basic concepts that are applicable to more architectures.

This is a subsection of Real World kernels, under concepts and design. Hope I get no controversy and that everything I say is more or less right, the section is not finished, and I will be adding some history on Darwin. I gave special attention to the Tanenbaum / Torvalds section, I hope I have not misunderstood anything and that the subject is treated as it happened… If not let me know, please.

Real World Kernels

In this section we will be discussing the architectures and goals of already quite deployed kernels. This section is not intended to be a full list of
all available kernels but a chosen set of well known ones. As we will see, each of this kernel is architecturally different from the others, but
all of them have had success in their field, thus we will be see that most designs can lead to success depending on the target.

Most of the kernels that are going to be treated are open source, as it hard to get good design information on up to date closed commercial kernels.

BSD:

BSD will be taken as en example of a classic UNIX operating system. Unix was created in 1969 at Bell Laboratories by Ken Thompson, who had been working with other
colleagues developing MULTICS, which had the basic ideas of the later to come Unix, the problem was it that it was too big and slow.
Thompson and Ritchie worked on Unix for many years, rewriting it to C, instead of the previously used assembly language.

C was developed at Bell Laboratories and became the main language for operating system development, as Unix was being developed it became widely used within
Bell Laboratories, and in 1976 was released the first version for outside Bell Laboratories. Unix was becoming popular due to its modularity and clean design.

The biggest Unix developer outside Bell Labs. became University of California at Berkeley, their first work was started in 1978 by Ozalp Babaoglu and Bill Joy,
and their work was supported by the DARPA, their final work was released on 1993 as 4.4BSD, and was POSIX compilant.

%% SERIA MACO POSAR UN GR

Keeping on writing the concepts and design chapter… pretty boring one, hope it gets more exciting…

Kernel Classification

Kernels can be classified into four categories: monolithic kernels, microkernels, hybrid kernels and exokernels. This classification differentiates
the way the kernel is internally organized, and how each part interacts. There has been a lot of controversy on which is the best way to design a kernel,
each kind of kernel has it’s advantages and disadvantages, and all have been proved to be valid.

UserSpace vs. KernelSpace

This topic will be treated more deeply on following chapters, but some knowledge is required before proceeding. On all systems the kernel must be able
to guarantee stability. If an application crashes, it can not make the whole system go down. As the kernel is always resident into memory, we have to
guarantee that no user application will alter the memory the kernel is using.

To accomplish this protection, processors provide us with a hardware protection method. The processor can enter into different states( rings), each
having different access privileges. This way we can separate a running space for the kernel and another for the user applications. The kernel has access to all
memory and I/O devices, but when we are running in userspace we can only access to “our” memory region and the I/O that the kernel has made availible
to userspace.

The switch between kernelspace and userspace is done via interrupts or traps, often called system calls. A userspace can issue a system call, then the system
enter into kernelspace, validates the call and proceeds to execution of it.

It is important to notice which parts of the operating system are running under kernelspace as this is the main difference between different kernels
and an issue of performance, as switching from kernelspace to userspace or vice-verse has a great performance penalty.

Kernelspace is also called supervisor mode, protected mode or ring0.

Monolithic Kernel

A monolithic kernel includes all of its services inside the kernel, everything runs in kernelspace this includes the core kernel services and the drivers.
This way the number of switches between userspace and kernelspace is the minimum, thus theoretically increassing the performance of the system.
This does not mean that all supported drivers have to be on memory at the startup time, but if we need some driver, it will have to be dynamically loaded
so as to be able to use it, this is often called kernel modules.

A main issue with monolithic kernel is portability, being hard to achieve as each part of the code has to be rewritten for each specific architecture,
the monolithic OS is not portable. But if we take specific examples of monolithic kernels, we will see that portability is achieved through pre-processor
directives which specify which part of the code are to be compiled for which hardware.

A highly criticized problem of monolithic kernel is the space they need to run, as every service has to be loaded into memory, this can result on big
kernels, this can be partially solved by loading dynamically the needed parts of the kernel, but once loaded they reside in memory and as long as
we need them they can not be unloaded.

The main advantage of monolithic kernels is said to be the ease of development and performance, which is supposed to be better, at least on X86 which has
a great penalty for context switching.

The philosophy behind monolithic kernels is that all code inside the kernel must be correct, as if any part of the kernel fails the whole system can crash, for
example, if a device driver is badly coded it should not be included and the device will not have support.

Microkernel

The microkernel approach consists in defining a very simple abstraction over the hardware, with a minimal set of primitives to implement the core services
of the operating system. This consists on running the minimum necessary services under protected mode, and the rest of the services run as process
under userspace, so what is left to the kernel are the basic services like memory allocation, scheduling and messaging.

Microkernel are supposed to be more responsive as much of the tasks can be interrupted anytime ( preemptive userspace ). There is a benefit for multi-processor
and distributed systems, as it is easier to separate each service, but a drawback is the number of context switches required, which tend to be much
higher than those of monolithic kernels.

In contrast to monolithic kernel, microkernels seek to be platform independent, only the part which communicates directly to the hardware has to be
rewritten for every system, this part is called HAL\footnote{Hardware Abstraction Layer}. All the services do not need to be rewritten as they rely on the
standard API of the HAL.

Hybrid kernels

Hybrid kernel are a mixture of monolithic kerels and monolithic kernels, they try to get the best of each one. The idea is having some non-essential code
in kernelspace. Most modern operating systems fall into this category. It has to be clear the difference between monolithic kernel that load modules dynamically and
hybrid kernel, hybrid still have services as process while have some non indispensable code inside the kernel, which helps improve the performance of the
whole system.

Exokernels

This approach to kernel design is completely different from previous architectures. The idea is that the developer has complete control of the hardware. The
kernel is really minimal, it just contains the protection mechanisms and the multiplexing of resources. Classic kernels hide the hardware behind some kind
of abstraction layer, so after allocating some space, one can not where this space physically resides.

The main purpose of exokernels is that an application can request any physical resource and the kernel just assures that the resource is free and lets the
application access to it.

The rest of the functions are provided by a library operating system. This library provides the interface for application programmers as if they were using
a full OS.

Theoretically it is possible to run many operating systems on top of an exokernel, giving each opertaing system different resource capabilities.

While Monolithic and Microkernel are well defined terms, the exokernels have many slightly different variants such as, nanokernel, picokernel, cache kernel,
virtualizing kernel, etc…

Via Xavi Caball

Well… it’s easter holidays and I have to work a little more on the University project, maybe not just a little, but a lot… This is a subsection of the chapter : Concepts and Design

What is an Operating System:

An operating system is a program that works as an intermediate layer between the computer’s hardware and the applications the user is willing to use.
So the main purpose is to let the user use the hardware, another goal of the operating system is to use the Hardware in the most efficient manner.

Every computer system can be divided into four components : users, programs/applications, operating system and hardware.
PICTURE TO BE MADE : CERCLES QUE MOSTRIN DE DINS A FORA CADA PART

The hardware contains the CPU, the memory and the I/O devices, and is responsible of providing the computing resources. The applications are programs
dedicated to solve a problem, and communicate with the operating system to satisfy their need for resources. As we will see, many users can
be using different resources, so the operating system has to coordinate and control the use of the hardware among different users and applicatios.

The operating system is just an environment, for other programs to be able to work, we can see it as an allocator for resources, everything runs
on top of it, and the operating system “decides“:

• What is being executed
• Where the data is held
• Which resources can be accessed

There is not any standard definition of which are the functions of the operating system. We can think of an operating system as everything that
comes in the box when you buy it. But this is a too broad definition, so from here on we will call operating system to the program that runs
all the time on the machine ( also called Kernel\footnote{Derived from the botanical meaning of all that is within the outer coat of the seed.}). From here on the terms operating system and Kernel mean the same thing.

To understand what a kernel is we will look at the functions it must be able to perform, looking historically which have been the needs and how have they been solved.

Mid 50s – mid 60s: Batch Systems

The input devices were normally punched cards or magnetic tapes. The operator had to load the program, data and the operation information to the computer
which processed the data and after some time give it to an output. The output usually consisted of a card puncher, a printer or magnetic tape writer.
The operating system (monitor) was always resident in memory and had to do very little, just transfer control automatically from job to job.
Usually the jobs which had similar resource need where processed together as group ( batch group) , making more efficient use of the hardware.

Advantages of batch systems compared to older systems:

• Less work to the operator.
• Increased performance, one job could start after the previous one just finished.

Disavanatges:

• From user standpoint the turn-around time can be large.
• Difficult to debug programs.
• Lack of protection, one batch job can affect other batched jobs.
• A job can corrupt the monitor.
• A job could enter an infinite loop.

mid 60s – late 60s: Spooling Batch Systems

On batch systems, reading from the punched cards caused a long CPU idle time, and reading from a magnetic tape was faster, so most computer systems
contained an smaller computer that transfered the information from the cards to magnetic tapes, which where later processed by the batch system.
The output was also written in a tape for later use on a smaller computer which transfered it to the desired support.

As an extension of the above idea, it was logical that a timer was added to the computer, this timer interrupts the computer while performing a job and
starts a I/O transaction. While the I/O transaction is done the computer can continue processing. The computer can now perform I/O in parallel with computation,
it became possible to have a computer read a set of cards to a tape, write to a tape or print, all this while computing. This process is called SPOOLing:
Simultaneous Peripheral Operation OnLine. Spooling Batch is the simplest of the multiprograming systems.

60s – present: Multiprograming

As more memory was available to the system it was possible to create systems that would load several jobs into memory and cycle through them in some order,
working on each for some amount of time. So the idea is that th eoperating system keeps several jobs into memory, the monitor ( operating system ) picks one
and begins it’s execution, eventually the job may have to way for some I/O, so the monitor just chooses another jobs, and continues executing it. The CPU
never idles as long as there is some job in memory that can be executed. This way we make a more efficient use of the computing resources.

Now the monitor is responsible for:

• Starting user jobs.
• Spooling operations.
• I/O for user jobs.
• Switch between user jobs.
• Ensuring protection for the above.

70s – present: Timesharing Systems

The idea of multiprogramming was extended to allow multiple terminals to be connected to the computer, with each terminal being associated to a job, now
called process. If the context switch between process was made fast enough, the user on the terminal had the impression of having direct access to the machine.

An interactive system provides response to the user based on the input, this response time should be very small. Normally the system has all process on memory
( can be virtual memory ), and gives an small slice of time to each one. Timesharing, also called multitask, systems are much more complex than
multiprogrammed systems. In both, several jobs must be kept simultaneously into memory, so the system must have some sort of protection scheme. To be able to
obtain a short response time, switch between jobs have to be done really often, so jobs may have to be backed to disk in order to be able to have other
processes loaded into memory. To ensure orderly execution the system must provide synchronization and communication mechanisms.

70s: Personal Computers

In late 70s, personal computers appeared, and after some time they were inexpensive enough to become popular. The operating system need for this comupter
has evolved to give a maximum emphasis to the convenience and responsiveness of the system.

Parallel, Real-Time and Distributed Systems

This is out of the scope of the project, so we will be covering this even more superficially than the rest of the operating system history.

A real-time system is one that execute programs that have a guaranteed time to finish. This can be either soft or hard real time, being soft more
permissive with the timings, with hard real time a program will not be executed if it will not have finished in the expected time. Often hard real time
operating systems can only perform a small very specific set of tasks, normally called dedicated systems.

A multiprocessor is one with more than one CPU, it can be divided into the following:

• Shared Memory Multiprocessor: Multiple CPU, all access the same memory. Care has to be taken to avoid bus collision.
• Distributed Memory Multiprocessor: Each processor has it’s own memory, communication is more compicated.

Distributed:

• Networked Systems: Multiple computers networked together, sharing resources. Users are aware of the computers that make the system.
• Distributed Systems: Transparent to the user, often include resource redundancy and sharing of workload.