<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*omi-er7TsIt8hJtS_hwL7g.png"></figure>As a software engineer, you know that software architecture design is crucial to any software project. The C4 model is a popular approach for designing software architecture that provides a clear, concise visual representation of the system’s architecture.
In this article, we will dive into the C4 model and explore how it can be used to create a simple C4 diagram for a given scenario. Whether you are a software architect, developer, or project manager, understanding how to draw a C4 diagram can help you communicate the architecture effectively to stakeholders and ensure that the system is scalable, maintainable, and flexible. So, let’s get started and unlock the power of the C4 model!
<h3>C4 Model</h3>
A C4 diagram is a type of diagram used in software engineering to represent the architecture of a software system. It consists of four types of diagrams:
<ol>
<li>Context diagram</li>
<li>Containers diagram</li>
<li>Components diagram</li>
<li>Code diagram</li>
</ol>
To get understand the above four diagrams let’s get a simple scenario.
<h4>Scenario</h4>
An Internet Banking System, Provides all Internet banking functionalities to customers via mobile application or web application. And it consists of the mainframe banking system which stores all core banking information about customers, accounts, transitions, etc. Also, there is an email system to send emails.
<h4>Context diagram</h4>
Context diagram represents a high-level overview of the system’s environment and external dependencies. It includes things like users, external systems, and other factors that may influence the system’s design.
Let’s draw the context diagram for the above scenario:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*uQIYdpmNKbeh5rrgezO4nw.png"><figcaption>Level 01 — System Context Diagram</figcaption></figure>Person: Any external stakeholders who interact with the system. These can be end-users, customers, vendors, partners, or any other external entity that is part of the system’s ecosystem. In this scenario, a person will be a personal banking customer.
External factors: This can include anything outside of the system that can impact its design or performance. For example, an external factor could be a regulatory requirement that the system needs to comply with or a third-party API that the system needs to integrate with. There are two external factors in this scenario:
<ol>
<li>Mainfram Banking System</li>
<li>Email System</li>
</ol>
<h4>Container diagram</h4>
These are high-level components that make up the system, such as web servers, application servers, databases, etc. Each container should have a clear responsibility and interact with other containers in a specific way.
Let’s draw the container diagram for the above scenario:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*T81EPT3DRWOAYZYxnwqk6g.png"><figcaption>Level 02 — System Container Diagram</figcaption></figure><h4>Components diagram</h4>
A components diagram represents the building blocks of a particular container, representing the software modules or libraries that make up the system. Each component should have a clear responsibility and communicate with other components in a specific way.
Let’s draw the components diagram for API Application Container:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*OgHdx07IF4DlywPQKTRsRg.png"><figcaption>Level 03 — Components diagram of API Application</figcaption></figure>According to requirements, you can draw the components diagram for other containers as well.
<h4>Code diagram</h4>
This represents the implementation details of each component, such as classes, functions, and modules. This component is not usually included in the diagram, but it is important to keep it in mind when designing the system.
Let’s draw the code diagram for the Mainframe System Facade Component:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*y5YiHOA7uJgmlUN6O-jGfg.png"><figcaption>Level 04 — Code diagram of Mainframe System Facade</figcaption></figure>This is an optional level of detail and is often available on-demand from tooling such as IDEs. Ideally, this diagram would be automatically generated using tooling (e.g. an IDE or UML modeling tool), and you should consider showing only those attributes and methods that allow you to tell the story that you want to tell. This level of detail is not recommended for anything but the most important or complex components.
<h3>Conclusion</h3>
In this article, we have explored the C4 model in-depth, including its components, benefits, and best practices. We have also provided a step-by-step guide on how to create a simple C4 diagram for your software system, using a practical example scenario.
Remember that the C4 model is just one of many approaches to software architecture design, and it should be used in conjunction with other best practices and methodologies. By keeping an open mind and adopting a holistic approach to software development, you can design software systems that are both functional and easy to maintain.
In conclusion, the C4 model is a powerful tool that can help you unlock the full potential of your software systems. Whether you are a software architect, developer, or project manager, understanding the C4 model and how to use it can give you a significant advantage in today’s competitive software development industry.
References:
<ul><li><a href="https://c4model.com/">c4model.com</a></li></ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d2599d47d39d" width="1" height="1" alt="">

Software Architecture Design with the C4 Model

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*aVK42kz2qp7iyJ5_l82Sxw.jpeg"></figure>The Factory Pattern is a creational design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created. In TypeScript, you can implement the Factory Pattern using an abstract class or an interface to define the Factory and concrete classes to implement it.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*AKkJmgYiHnHucU8rKeVfmw.png"><figcaption>UML Diagram — Factory Pattern</figcaption></figure><h3>Implementation</h3>
In this article, We will implement Factory Pattern using an interface.
Let’s assume a simple calculator doing calculations using two numbers. Included methods are adding, subtracting, multiplying, and dividing.
<ol><li>Create a common interface for operation:</li></ol>
<pre>interface Operation { execute(number1: number, number2: number): number; }</pre>
2. Implement the operation interface for adding, subtracting, multiplying, and dividing:
<pre> class AddOperation implements Operation { execute(number1: number, number2: number): number { return number1 + number2; } } class SubtractOperation implements Operation { execute(number1: number, number2: number): number { return number1 - number2; } } class MultiplyOperation implements Operation { execute(number1: number, number2: number): number { return number1 * number2; } } class DivideOperation implements Operation { execute(number1: number, number2: number): number { return number1 / number2; } }</pre>
3. Add a factory call to create an instance from operation implementations:
<pre>class OperationFactory { getInstance(operation: string): Operation { switch (operation) { case '+': return new AddOperation(); case '-': return new SubtractOperation(); case '*': return new MultiplyOperation(); case '/': return new DivideOperation(); default: throw new Error('Invalid operation'); } }</pre>
4. Now you can execute any operation by simply parsing a string:
<pre>const operationFactory = new OperationFactory(); const operation = operationFactory.getInstance('+'); console.log(operation.execute(1, 2));</pre>
In this article, we discussed the Factory Pattern design pattern in TypeScript. There are many more. Let’s discuss others in the next articles.
<blockquote>You Don’t Need to ‘Reinvent the Wheel’</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=195bed98cd71" width="1" height="1" alt="">

Design Patterns in TypeScript: Factory Pattern

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*rMBNCGgH2DBUu30WMIkBOw.png"></figure>TypeScript is a superset of JavaScript that adds optional static typing and other features to the language. TypeScript can be used to write complex applications, and design patterns can be used to structure and organize code in a reusable and maintainable way.
<h3>Singleton</h3>
The singleton design pattern is used when you want to ensure that only one instance of a particular class is created throughout the lifetime of a program, and that instance can be accessed globally.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/439/1*qS78T3E7l4fLKhv08dmF-Q.png"><figcaption>Singleton — UML Diagram</figcaption></figure><h4>Simple Implementation</h4>
In this section, we consider the implementation of Singleton using TypeScript.
1. Create the Singleton class with static private property of the Singleton class:
<pre>class Singleton { private static _instance: Singleton }</pre>
2. Add a private constructor to avoid creating a direct instance from the class.
<pre>private constructor() {}</pre>
3. Add a method to create and access the class instance. This method creates a new class instance when the first time it uses. Otherwise, it returns the already created instance.
<pre> static get instance(): Singleton { if (!this._instance) { this._instance = new Singleton() } return this._instance }</pre>
Complete code:
<pre>class Singleton { private static _instance: Singleton private constructor() {} static get instance(): Singleton { if (!this._instance) { this._instance = new Singleton() } return this._instance } }</pre>
<h4>Advance implementation</h4>
In this section, Singleton implemented using TypeScript with asynchronous initialization. Consider the following code:
<pre>class Singleton { private static _instance: Singleton private data: string private constructor() {} public static async getInstance(): Promise&lt;Singleton&gt; { if (!Singleton._instance) { Singleton._instance = new Singleton() Singleton._instance.data = await Singleton._instance.loadData() } return Singleton._instance } private async loadData(): Promise&lt;string&gt; { // simulate async data loading return new Promise&lt;string&gt;((resolve, reject) =&gt; { setTimeout(() =&gt; { resolve("Some data loaded asynchronously") }, 1000); }); } public getData(): string { return this.data } }</pre>
The getInstance method is static and async, which returns a Promise that resolves to the singleton instance. It first checks whether the instance variable is null and initializes it by calling the constructor and loading the data asynchronously.
The loadData the method simulates some asynchronous data loading by returning a Promise that resolves to some string after a timeout.
In this article, we discuss the Singleton design pattern in TypeScript. There are many more. Let’s discuss others in the next articles.
<blockquote>You Don’t Need to ‘Reinvent the Wheel’</blockquote>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=438eff385247" width="1" height="1" alt="">

Design Patterns in TypeScript: Singleton

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*U1B7v2Fy8Y1Z2i5lW-gAGg.jpeg"></figure>If you are an Apple developer you may hear about Swift language. Swift is friendly to new programmers. It’s an industrial-quality programming language that’s as expressive and enjoyable as a scripting language. This article focuses on Structures, Classes, and Protocols in Swift language.
<h3>Structures and Classes</h3>
Structures and classes are general-purpose, flexible constructs that become the building blocks of your program’s code. You define properties and methods to add functionality to your structures and classes using the same syntax you use to define constants, variables, and functions. Swift doesn’t require you to create separate interface and implementation files for custom structures and classes. In Swift, you define a structure or class in a single file, and the external interface to that class or structure is automatically made available for other code to use.
Common things in Structures and Classes both have:
<ul>
<li>Define properties to store values</li>
<li>Define methods to provide functionality</li>
<li>Define subscripts to provide access to their values using subscript syntax</li>
<li>Define initializers to set up their initial state</li>
<li>Be extended to expand their functionality beyond a default implementation</li>
<li>Conform to protocols to provide standard functionality of a certain kind</li>
</ul>
Rather than those Classes having more additional capabilities that structures do not have:
<ul>
<li>Inheritance enables one class to inherit the characteristics of another.</li>
<li>Typecasting enables you to check and interpret the type of a class instance at runtime.</li>
<li>Deinitializers enable an instance of a class to free up any resources it has assigned.</li>
<li>Reference counting allows more than one reference to a class instance.</li>
</ul>
Now, Let’s talk about syntax
<h4>Definition Syntax</h4>
<pre>struct SomeStructure {</pre>
<pre>// structure definition goes here</pre>
<pre>}</pre>
<pre>class SomeClass {</pre>
<pre>// class definition goes here</pre>
<pre>}</pre>
<h4>Instantiation Syntax</h4>
<pre>let someStructure = SomeStructure() // struct Instantiation</pre>
<pre>let someClass = SomeClass() // class Instantiation</pre>
<h4>Accessing Properties</h4>
<pre>someStructure.property1 // Accessing properties in structure someClass.property1 // Accessing properties in class</pre>
<h4>Choosing between Structures and Classes</h4>
Structures and classes are both good options for storing data and modeling behavior in your apps, but their similarity can make choosing one over the other difficult.
The following things are helpful in choosing between Structures and Classes:
<ul>
<li>Use structures by default.</li>
<li>Use classes when you need Objective-C interoperability.</li>
<li>Use classes when you need to control the identity of the data you’re modeling.</li>
<li>Use structures along with protocols to adopt behavior by sharing implementations.</li>
</ul>
<h3>Protocols</h3>
A protocol is a set of methods, properties, and other specifications that are tailored to a specific task or piece of functionality. A class, structure, or enumeration can then adopt the protocol to provide an actual implementation of those requirements. Any type that meets the protocol’s requirements is said to conform to that protocol.
You can extend a protocol to implement some of these requirements or to implement additional functionality that conforming types can use, in addition to specifying requirements that conforming types must meet.
<h4>Protocol Syntax</h4>
Definition Syntax
<pre>protocol SomeProtocol {</pre>
<pre>// protocol definition goes here</pre>
<pre>}</pre>
Custom types state that they adopt a particular protocol by placing the protocol’s name after the type’s name, separated by a colon, as part of their definition. Multiple protocols can be listed, and are separated by commas:
<pre>struct SomeStructure: FirstProtocol, AnotherProtocol {</pre>
<pre>// structure definition goes here</pre>
<pre>}</pre>
If a class has a superclass, list the superclass name before any protocols it adopts, followed by a comma:
<pre>class SomeClass: SomeSuperclass, FirstProtocol, AnotherProtocol {</pre>
<pre>// class definition goes here</pre>
<pre>}</pre>
This is a very brief introduction to Structures, Classes, and Protocols in Swift. if you want to get more about those go and do some coding in Swift.
<blockquote>“Doing things get more understanding”</blockquote>
Reference:
<a href="https://docs.swift.org/">docs.swift.org</a>
<a href="https://developer.apple.com/">developer.apple.com</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=31bc28adbf8a" width="1" height="1" alt="">

Structures, Classes, and Protocols in Swift

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*dDP-BIUDhq7R76qFdIKDyg.jpeg"></figure>This is part 9 of Implement Your Own Operating System. In this article, we will discuss how to run a simple program in user mode.
<h3>User Mode</h3>
User mode is now almost within our reach, there are just a few more steps required to get there. Although these steps might seem easy the way they are presented in this chapter, they can be tricky to implement, since there are a lot of places where small errors will cause bugs that are hard to find.
<h3>01. Segments for User Mode</h3>
To enable user mode we need to add two more segments to the GDT. They are very similar to the kernel segments.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/862/1*E_q91paDnxD_ead6Y4L2_Q.png"><figcaption>The segment descriptors are needed for user mode.</figcaption></figure>The difference is the DPL, which now allows code to execute in PL3. The segments can still be used to address the entire address space, just using these segments for user-mode code will not protect the kernel. For that we need paging.
<h3>02. Setting Up For User Mode</h3>
There are a few things every user-mode process needs:
<ul>
<li>Page frames for code, data, and stack. At the moment it suffices to allocate one-page frame for the stack and enough page frames to fit the program’s code. Don’t worry about setting up a stack that can be grown and shrunk at this point in time, focus on getting a basic implementation work first.</li>
<li>The binary from the GRUB module has to be copied to the page frames used for the program's code.</li>
<li>A page directory and page tables are needed to map the page frames described above into memory. At least two-page tables are needed, because the code and data should be mapped in at 0x00000000 and increasing, and the stack should start just below the kernel, at 0xBFFFFFFB, growing towards lower addresses. The U/S flag has to be set to allow PL3 access.</li>
</ul>
It might be convenient to store this information in a struct representing a process. This process struct can be dynamically allocated with the kernel’s malloc function.
<h3>03. Entering User Mode</h3>
The only way to execute code with a lower privilege level than the current privilege level (CPL) is to execute an iret or lret instruction - interrupt return or long return, respectively.
To enter user mode we set up the stack as if the processor had raised an inter-privilege level interrupt. The stack should look like the following:
<pre>[esp + 16] ss ; the stack segment selector we want for user mode [esp + 12] esp ; the user mode stack pointer [esp + 8] eflags; the control flags we want to use in user mode [esp + 4] cs ; the code segment selector [esp + 0] eip ; the instruction pointer of user mode code to execute</pre>
The instruction iret will then read these values from the stack and fill in the corresponding registers. Before we execute iret we need to change to the page directory we set up for the user-mode process. It is important to remember that to continue executing kernel code after we’ve switched PDT, the kernel needs to be mapped in. One way to accomplish this is to have a separate PDT for the kernel, which maps all data at 0xC0000000 and above, and merge it with the user PDT (which only maps below 0xC0000000) when performing the switch. Remember that the physical address of the PDT has to be used when setting the register cr3.
The register eflags contains a set of different flags, specified in section 2.3 of the Intel manual [33]. Most important for us is the interrupt enable (IF) flag. The assembly code instruction sti can’t be used in privilege level 3 for enabling interrupts. If interrupts are disabled when entering user mode, then interrupts can’t be enabled once user mode is entered. Setting the IF flag in the eflags entry on the stack will enable interrupts in user mode since the assembly code instruction iret will set the register eflags to the corresponding value on the stack.
For now, we should have interrupts disabled, as it requires a little more work to get inter-privilege level interrupts to work properly.
The value eip on the stack should point to the entry point for the user code - 0x00000000 in our case. The value esp on the stack should be where the stack starts - 0xBFFFFFFB (0xC0000000 - 4).
The values cs and ss on the stack should be the segment selectors for the user code and user data segments, respectively. The lowest two bits of a segment selector is the RPL - the Requested Privilege Level. When using iret to enter PL3, the RPL of cs and ss should be 0x3. The following code shows an example:
<pre> USER_MODE_CODE_SEGMENT_SELECTOR equ 0x18 USER_MODE_DATA_SEGMENT_SELECTOR equ 0x20 mov cs, USER_MODE_CODE_SEGMENT_SELECTOR | 0x3 mov ss, USER_MODE_DATA_SEGMENT_SELECTOR | 0x3</pre>
The register ds, and the other data segment registers should be set to the same segment selector as ss. They can be set the ordinary way, with the mov assembly code instruction.
We are now ready to execute iret. If everything has been set upright, we should now have a kernel that can enter user mode.
<h3>04. Using C for User Mode Programs</h3>
When C is used as the programming language for user-mode programs, it is important to think about the structure of the file that will be the result of the compilation.
The reason we can use ELF [18] as the file format for the kernel executable is that GRUB knows how to parse and interpret the ELF file format. If we implemented an ELF parser, we could compile the user mode programs into ELF binaries as well. We leave this as an exercise for the reader.
One thing we can do to make it easier to develop user-mode programs is to allow the programs to be written in C, but compile them to flat binaries instead of ELF binaries. In C the layout of the generated code is more unpredictable and the entry point, main, might not be at offset 0 in the binary. One common way to work around this is to add a few assembly code lines placed at offset 0 which calls main:
<pre> extern main</pre>
<pre> section .text ; push argv ; push argc call main ; main has returned, eax is return value jmp $ ; loop forever</pre>
If this code is saved in a file called start.s, then the following code shows an example of a linker script that places these instructions first in executable (remember that start.s gets compiled to start.o):
<pre> OUTPUT_FORMAT("binary") /* output flat binary */</pre>
<pre> SECTIONS { . = 0; /* relocate to address 0 */</pre>
<pre> .text ALIGN(4): { start.o(.text) /* include the .text section of start.o */ *(.text) /* include all other .text sections */ }</pre>
<pre> .data ALIGN(4): { *(.data) }</pre>
<pre> .rodata ALIGN(4): { *(.rodata*) } }</pre>
Note: *(.text) will not include the .text section of start.o again.
With this script, we can write programs in C or assembler (or any other language that compiles to object files linkable with ld), and it is easy to load and map for the kernel (.rodata will be mapped in as writeable, though).
When we compile user programs we want the following GCC flags:
<pre>-m32 -nostdlib -nostdinc -fno-builtin -fno-stack-protector -nostartfiles -nodefaultlibs</pre>
For linking, the followings flags should be used:
<pre>-T link.ld -melf_i386 # emulate 32 bits ELF, the binary output is specified # in the linker script</pre>
The option -T instructs the linker to use the linker script link.ld.
Create the following files to run the user-mode program:
<a href="https://medium.com/media/796230e3814535d66ddea0f343e6945f/href">https://medium.com/media/796230e3814535d66ddea0f343e6945f/href</a>Update following two files in your code:
<a href="https://medium.com/media/ba32197861ce12412fcb42aabe7d59a3/href">https://medium.com/media/ba32197861ce12412fcb42aabe7d59a3/href</a>Well done! We have successfully run a simple program in user mode. We will meet the next article Implement Your Own Operating System (Part 10).
Completed project: <a href="https://github.com/imashaWe/noxOS">Github</a>
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=e49dd7b505a5" width="1" height="1" alt="">

Implement Your Own Operating System (Part 09)

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*vaCCHIBuXIbiDVGibzbzhg.jpeg"></figure>This is part 8 of the Implement Your Own Operating System article series. In this article, we will discuss page frame allocation.
<h3>Page Frame Allocation</h3>
How does the OS know which parts of memory are free to utilize while using virtual memory? The page frame allocator plays this duty.
<h3>01. How Much Memory is There?</h3>
First, we need to know how much memory is available on the OS's computer. The easiest way to do this is to read it from the multiboot structure [19] passed to us by GRUB. GRUB collects the information we need about the memory — what is reserved, I/O mapped, read-only, etc. We must also make sure that we don’t mark the part of the memory used by the kernel as free (since GRUB doesn’t mark this memory as reserved). One way to know how much memory the kernel uses is to export labels at the beginning and the end of the kernel binary from the linker script:
<a href="https://medium.com/media/19da4a1f07fe4499e4e60c0b8d55e6b0/href">https://medium.com/media/19da4a1f07fe4499e4e60c0b8d55e6b0/href</a>These labels can directly be read from assembly code and pushed on the stack to make them available to C code:
<pre> extern kernel_virtual_start extern kernel_virtual_end extern kernel_physical_start extern kernel_physical_end</pre>
<pre> ; ...</pre>
<pre> push kernel_physical_end push kernel_physical_start push kernel_virtual_end push kernel_virtual_start</pre>
<pre> call kmain</pre>
This way we get the labels as arguments to kmain. If you want to use C instead of assembly code, one way to do it is to declare the labels as functions and take the addresses of these functions:
<pre> void kernel_virtual_start(void);</pre>
<pre> /* ... */</pre>
<pre> unsigned int vaddr = (unsigned int) &amp;kernel_virtual_start;</pre>
If you use GRUB modules you need to make sure the memory they use is marked as reserved as well.
Note that the available memory does not need to be contiguous. In the first 1 MB, there are several I/O-mapped memory sections, as well as memory used by GRUB and the BIOS. Other parts of the memory might be similarly unavailable.
It’s convenient to divide the memory sections into complete page frames, as we can’t map part of pages into memory.
<h3>02. Managing Available Memory</h3>
How do we know which page frames are in use? The page frame allocator needs to keep track of which are free and which aren’t. There are several ways to do this: bitmaps, linked lists, trees, the Buddy System (used by Linux), etc. For more information about the different algorithms see the article on OSDev
Bitmaps are quite easy to implement. One bit is used for each page frame and one (or more) page frames are dedicated to storing the bitmap.
<h3>03. How Can We Access a Page Frame?</h3>
The page frame allocator returns the physical start address of the page frame. This page frame is not mapped in — no page table points to this page frame. How can we read and write data to the frame?
We need to map the page frame into virtual memory, by updating the PDT and/or PT used by the kernel. What if all available page tables are full? Then we can’t map the page frame into memory, because we’d need a new page table — which takes up an entire page frame — and to write to this page frame we’d need to map its page frame. Somehow this circular dependency must be broken.
One solution is to reserve a part of the first-page table used by the kernel (or some other higher-half page table) for temporarily mapping page frames to make them accessible. If the kernel is mapped at 0xC0000000 (page directory entry with index 768), and 4 KB page frames are used, then the kernel has at least one-page table. If we assume - or limit us to - a kernel of size at most 4 MB minus 4 KB we can dedicate the last entry (entry 1023) of this page table for temporary mappings. The virtual address of pages mapped using the last entry of the kernel’s PT will be:
<pre>(768 &lt;&lt; 22) | (1023 &lt;&lt; 12) | 0x000 = 0xC03FF000</pre>
After we’ve temporarily mapped the page frame we want to use as a page table, and set it up to map in our first-page frame, we can add it to the paging directory, and remove the temporary mapping.
<h3>04. A Kernel Heap</h3>
So far we’ve only been able to work with fixed-size data, or directly with raw memory. Now that we have a page frame allocator we can implement malloc and free to use in the kernel.
Kernighan and Ritchie [8] have an example implementation in their book [8] that we can draw inspiration from. The only modification we need to do is to replace calls to sbrk/brk with calls to the page frame allocator when more memory is needed. We must also make sure to map the page frames returned by the page frame allocator to virtual addresses. A correct implementation should also return page frames to the page frame allocator on call to free, whenever sufficiently large blocks of memory are freed.
new paging.c file:
<a href="https://medium.com/media/63955d5e4422b8b96964c18334caa853/href">https://medium.com/media/63955d5e4422b8b96964c18334caa853/href</a>Well done! We have discussed how to do page frame allocation. We will meet the next article Implement Your Own Operating System (Part 09).
Completed project: <a href="https://github.com/imashaWe/noxOS">Github</a>
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=50b12e59c283" width="1" height="1" alt="">

Implement Your Own Operating System (Part 08)

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*WSoL4I7yyKmbTtysWsoAdA.jpeg"></figure>In this article, we will discuss virtual memory and Paging implementation.
<h3>Virtual Memory</h3>
Virtual memory is an abstraction of physical memory. The purpose of virtual memory is generally to simplify application development and to let processes address more memory than what is actually physically present in the machine. We also don’t want applications messing with the kernel or other applications’ memory due to security.
In the x86 architecture, virtual memory can be accomplished in two ways: segmentation and paging. Managing memory is a big part of what an operating system does. Paging and page frame allocation deals with that.
<h3>Paging</h3>
Segmentation translates a logical address into a linear address. Paging translates these linear addresses onto the physical address space and determines access rights and how the memory should be cached.
<h4>Why Paging?</h4>
Paging is the most common technique used in x86 to enable virtual memory. Virtual memory through paging means that each process will get the impression that the available memory range is 0x00000000 - 0xFFFFFFFF even though the actual size of the memory might be much less. It also means that when a process addresses a byte of memory it will use a virtual (linear) address instead of a physical one. The code in the user process won’t notice any difference (except for execution delays). The linear address gets translated to a physical address by the MMU and the page table. If the virtual address isn’t mapped to a physical address, the CPU will raise a page fault interrupt.
Paging is optional, and some operating systems do not make use of it. But if we want to mark certain areas of memory accessible only to code running at a certain privilege level (to be able to have processes running at different privilege levels), paging is the neatest way to do it.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*VmrgXAZsFhLtXPjwtsFlqA.png"><figcaption>Paging in x86</figcaption></figure>Ok, now move to the Paging implementation part!
<h3>1. Identity Paging</h3>
The simplest kind of paging is when we map each virtual address onto the same physical address, called identity paging. This can be done at compile time by creating a page directory where each entry points to its corresponding 4 MB frame. In NASM this can be done with macros and commands (%rep, times and dd). It can of course also be done at run-time by using ordinary assembly code instructions.
<h3>2. Enabling Paging</h3>
Paging is enabled by first writing the address of a page directory to cr3 and then setting bit 31 (the PG “paging-enable” bit) of cr0 to 1. To use 4 MB pages, set the PSE bit (Page Size Extensions, bit 4) of cr4. The following assembly code shows an example:
<a href="https://medium.com/media/696ada746443ae3b9141d36bffa33711/href">https://medium.com/media/696ada746443ae3b9141d36bffa33711/href</a><h3>3. A Few Details</h3>
It is important to note that all addresses within the page directory, page tables, and in cr3 need to be physical addresses to the structures, never virtual. This will be more relevant in later sections where we dynamically update the paging structures.
An instruction that is useful when updating a PDT or PT is invlpg. It invalidates the Translation Lookaside Buffer (TLB) entry for a virtual address. The TLB is a cache for translated addresses, mapping physical addresses corresponding to virtual addresses. This is only required when changing a PDE or PTE that was previously mapped to something else. If the PDE or PTE had previously been marked as not present (bit 0 was set to 0), executing invlpg is unnecessary. Changing the value of cr3 will cause all entries in the TLB to be invalidated.
An example of invalidating a TLB entry is shown below:
<pre>; invalidate any TLB references to virtual address 0 invlpg [0]</pre>
<h3>4. Paging and the Kernel</h3>
This section will describe how paging affects the OS kernel. We encourage you to run your OS using identity paging before trying to implement a more advanced paging setup, since it can be hard to debug a malfunctioning page table that is set up via assembly code.
<h3>5. Reasons to Not Identity Map the Kernel</h3>
If the kernel is placed at the beginning of the virtual address space — that is, the virtual address space (0x00000000, "size of kernel") maps to the location of the kernel in memory - there will be issues when linking the user mode process code. Normally, during linking, the linker assumes that the code will be loaded into the memory position 0x00000000. Therefore, when resolving absolute references, 0x00000000 will be the base address for calculating the exact position. But if the kernel is mapped onto the virtual address space (0x00000000, "size of kernel"), the user mode process cannot be loaded at virtual address 0x00000000 - it must be placed somewhere else. Therefore, the assumption from the linker that the user mode process is loaded into memory at position 0x00000000 is wrong. This can be corrected by using a linker script which tells the linker to assume a different starting address, but that is a very cumbersome solution for the users of the operating system.
This also assumes that we want the kernel to be part of the user mode process’ address space. As we will see later, this is a nice feature, since during system calls we don’t have to change any paging structures to get access to the kernel’s code and data. The kernel pages will of course require privilege level 0 for access, to prevent a user process from reading or writing kernel memory.
<h3>6. The Virtual Address for the Kernel</h3>
Preferably, the kernel should be placed at a very high virtual memory address, for example 0xC0000000 (3 GB). The user-mode process is not likely to be 3 GB large, which is now the only way that it can conflict with the kernel. When the kernel uses virtual addresses at 3 GB and above it is called a higher-half kernel. 0xC0000000 is just an example, the kernel can be placed at any address higher than 0 to get the same benefits. Choosing the correct address depends on how much virtual memory should be available for the kernel (it is easiest if all memory above the kernel virtual address should belong to the kernel) and how much virtual memory should be available for the process.
If the user-mode process is larger than 3 GB, some pages will need to be swapped out by the kernel. Swapping pages is not part of this book.
<h3>7. Placing the Kernel at 0xC0000000</h3>
To start with, it is better to place the kernel at 0xC0100000 than 0xC0000000, since this makes it possible to map (0x00000000, 0x00100000) to (0xC0000000, 0xC0100000). This way, the entire range (0x00000000, "size of kernel") of memory is mapped to the range (0xC0000000, 0xC0000000 + "size of kernel").
Placing the kernel at 0xC0100000 isn’t hard, but it does require some thought. This is once again a linking problem. When the linker resolves all absolute references in the kernel, it will assume that our kernel is loaded at physical memory location 0x00100000, not 0x00000000, since relocation is used in the linker script (see the section <a href="https://littleosbook.github.io/#linking-the-kernel">“Linking the kernel”</a>). However, we want the jumps to be resolved using 0xC0100000 as base address, since otherwise a kernel jump will jump straight into the user mode process code (remember that the user mode process is loaded at virtual memory 0x00000000).
However, we can’t simply tell the linker to assume that the kernel starts (is loaded) at 0xC01000000, since we want it to be loaded at the physical address 0x00100000. The reason for having the kernel loaded at 1 MB is because it can’t be loaded at 0x00000000, since there is BIOS and GRUB code loaded below 1 MB. Furthermore, we cannot assume that we can load the kernel at 0xC0100000, since the machine might not have 3 GB of physical memory.
This can be solved by using both relocation (.=0xC0100000) and the AT instruction in the linker script. Relocation specifies that non-relative memory-references should use the relocation address as a base in address calculations. AT specifies where the kernel should be loaded into memory. Relocation is done at link time by GNU ld, the load address specified by AT is handled by GRUB when loading the kernel and is part of the ELF format.
<h3>8. Higher-half Linker Script</h3>
We can modify the first linker script to implement this:
<a href="https://medium.com/media/f2ba5fa24ba873798761145ede308686/href">https://medium.com/media/f2ba5fa24ba873798761145ede308686/href</a><h3>9. Entering the Higher Half</h3>
When GRUB jumps to the kernel code, there is no paging table. Therefore, all references to 0xC0100000 + X won’t be mapped to the correct physical address, and will therefore cause a general protection exception (GPE) at the very best, otherwise (if the computer has more than 3 GB of memory) the computer will just crash.
Therefore, assembly code that doesn’t use relative jumps or relative memory addressing must be used to do the following:
<ul>
<li>Set up a page table.</li>
<li>Add identity mapping for the first 4 MB of the virtual address space.</li>
<li>Add an entry for 0xC0100000 that maps to 0x0010000</li>
</ul>
If we skip the identity mapping for the first 4 MB, the CPU would generate a page fault immediately after paging was enabled when trying to fetch the next instruction from memory.
Create paging paging files:
<a href="https://medium.com/media/d869eca7fb43b8bd533cc6ffcd5cc3a7/href">https://medium.com/media/d869eca7fb43b8bd533cc6ffcd5cc3a7/href</a>After the table has been created, an jump can be done to a label to make eip point to a virtual address in the higher half:
<pre>; assembly code executing at around 0x00100000 ; enable paging for both actual location of kernel ; and its higher-half virtual location</pre>
<pre> lea ebx, [higher_half] ; load the address of the label in ebx jmp ebx ; jump to the label</pre>
<pre> higher_half: ; code here executes in the higher half kernel ; eip is larger than 0xC0000000 ; can continue kernel initialisation, calling C code, etc.</pre>
The register eip will now point to a memory location somewhere right after 0xC0100000 - all the code can now execute as if it were located at 0xC0100000, the higher-half. The entry mapping of the first 4 MB of virtual memory to the first 4 MB of physical memory can now be removed from the page table and its corresponding entry in the TLB invalidated with invlpg.
<h3>10. Running in the Higher Half</h3>
There are a few more details we must deal with when using a higher-half kernel. We must be careful when using memory-mapped I/O that uses specific memory locations. For example, the frame buffer is located at 0x000B8000, but since there is no entry in the page table for the address 0x000B8000 any longer, the address 0xC00B8000 must be used, since the virtual address 0xC0000000 maps to the physical address 0x00000000.
Any explicit references to addresses within the multiboot structure need to be changed to reflect the new virtual addresses as well.
Mapping 4 MB pages for the kernel is simple, but wastes memory (unless you have a really big kernel). Creating a higher-half kernel mapped in as 4 KB pages saves memory but is harder to set up. Memory for the page directory and one page table can be reserved in the .data section, but one needs to configure the mappings from virtual to physical addresses at run-time. The size of the kernel can be determined by exporting labels from the linker script.
Create kheap files:
<a href="https://medium.com/media/f6e3edd1476e987354c96f9ff9297bb0/href">https://medium.com/media/f6e3edd1476e987354c96f9ff9297bb0/href</a>After, create commcommon files:
<a href="https://medium.com/media/5d6c198f633b067ea72d3fa831b8131d/href">https://medium.com/media/5d6c198f633b067ea72d3fa831b8131d/href</a>In the final step update kmainfile for install paging:
<a href="https://medium.com/media/9ad6df8493ccb725afb2aeedf278f475/href">https://medium.com/media/9ad6df8493ccb725afb2aeedf278f475/href</a>Well done! We have successfully implemented virtual memory paging in our OS!. We will meet the next article Implement Your Own Operating System (Part 08).
Completed project: <a href="https://github.com/imashaWe/noxOS">Github</a>
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a736c06f0df2" width="1" height="1" alt="">

Implement Your Own Operating System (Part 07)

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*CBw3uNxNJqtdBs5YdkGzkA.jpeg"></figure>The application logic is meant to be handled by the programs, not the kernel. To make application development easier, the kernel generates appropriate abstractions (for memory, files, and devices), executes activities on behalf of applications (system calls), and schedules processes.
In contrast to kernel mode, user mode is the environment in which the user’s programs run. This environment has fewer privileges than the kernel, thus (badly constructed) user programs will not be able to interfere with other programs or the kernel. Kernels that are poorly written are free to do anything they want.
Although there is still a long way to go before the OS built in this book can run applications in user mode, this article will demonstrate how to run a tiny program in kernel mode.
<h4>Loading an External Program</h4>
Where do we get the external program from? Somehow we need to load the code we want to execute into memory. More feature-complete operating systems usually have drivers and file systems that enable them to load the software from a CD-ROM drive, a hard disk, or other persistent media.
Instead of creating all these drivers and file systems, we will use a feature in GRUB called modules to load the program.
Ok, now we will implement step by step our simple program,
<h3>1. GRUB Modules</h3>
GRUB can load arbitrary files into memory from the ISO image, and these files are usually referred to as modules. To make GRUB load a module, edit the file iso/boot/grub/menu.lst and add the following line at the end of the file:
<pre>module /modules/program</pre>
Now create the folder iso/modules:
<pre>mkdir -p iso/modules</pre>
The application program will be created later in this chapter.
The code that calls kmain must be updated to pass information to kmain about where it can find the modules. We also want to tell GRUB that it should align all the modules on page boundaries when loading them.
To instruct GRUB how to load our modules, the “multiboot header” — the first bytes of the kernel — must be updated as follows:
<a href="https://medium.com/media/0d6830b95fef1ae764ba041de91f3c3e/href">https://medium.com/media/0d6830b95fef1ae764ba041de91f3c3e/href</a>GRUB will also store a pointer to a struct in the register ebx that, among other things, describes at which addresses the modules are loaded. Therefore, you probably want to push ebx on the stack before calling kmain to make it an argument for kmain.
<h3>2. Executing a Program</h3>
A program written at this stage can only perform a few actions. Therefore, a very short program that writes a value to a register suffices as a test program. Halting Bochs after a while and then check that register contains the correct number by looking in the Bochs log will verify that the program has run. This is an example of such a short program:
<a href="https://medium.com/media/b3fb28372bd01a611a65a779bbc032fb/href">https://medium.com/media/b3fb28372bd01a611a65a779bbc032fb/href</a><h3>3. Compiling</h3>
Since our kernel cannot parse advanced executable formats we need to compile the code into a flat binary. NASM can do this with the flag -f:
<pre>nasm -f bin program.s -o program</pre>
This is all we need. You must now move the file program to the folder iso/modules.
<h3>4. Finding the Program in Memory</h3>
Before jumping to the program we must find where it resides in memory. Assuming that the contents of ebx is passed as an argument to kmain, we can do this entirely from C.
The pointer in ebx points to a multiboot structure:
<a href="https://medium.com/media/fc6b819438da0c5a87d06daedd331bf8/href">https://medium.com/media/fc6b819438da0c5a87d06daedd331bf8/href</a>The pointer passed to kmain in the ebx the register can be cast to a multiboot_info_t pointer. The address of the first module is in the field mods_addr. The following code shows an example:
<pre>int kmain(/* additional arguments */ unsigned int ebx) { multiboot_info_t *mbinfo = (multiboot_info_t *) ebx; unsigned int address_of_module = mbinfo-&gt;mods_addr; }</pre>
However, before just blindly following the pointer, you should check that the module got loaded correctly by GRUB. This can be done by checking the flags field of the multiboot_info_t structure. You should also check the field mods_count to make sure it is exactly 1. For more details about the multiboot structure, see the multiboot documentation [19].
<h3>5. Jumping to the Code</h3>
The only thing left to do is to jump to the code loaded by GRUB. Since it is easier to parse the multiboot structure in C than assembly code, calling the code from C is more convenient (it can of course be done with jmp or call in assembly code as well). The C code could look like this:
<pre>typedef void (*call_module_t)(void); /* ... */ call_module_t start_program = (call_module_t) address_of_module; start_program(); /* we'll never get here, unless the module code returns */</pre>
After done above changes kmain.c file:
<a href="https://medium.com/media/e37bb1b6a33de1da4c665e25af54768d/href">https://medium.com/media/e37bb1b6a33de1da4c665e25af54768d/href</a>If we start the kernel, wait until it has run and entered the infinite loop in the program, and then halt Bochs, we should see 0xDEADBEEF in the register eax via the Bochs log. And also If all are fine you can see the characters which you typed in the terminal in com1.out file.
Well done! We have successfully started a program in our OS!. We will meet the next article Implement Your Own Operating System (Part 07).
Completed project: <a href="https://github.com/imashaWe/noxOS">Github</a>
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
Thank you!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9d4e5a63df69" width="1" height="1" alt="">

Implement Your Own Operating System (Part 06)

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*_VSLRDgEAFlkHysKWe0Fng.jpeg"></figure>In this part, we will discuss how to handle interrupts to read information from the keyboard. An interrupt occurs when a hardware device, such as the keyboard, the serial port, or the timer, signals the CPU that the state of the device has changed. The CPU itself can also send interrupts due to program errors, for example when a program references memory it doesn’t have access to, or when a program divides a number by zero. Finally, there are also software interrupts, which are interrupts that are caused by the int assembly code instruction and they are often used for system calls.
<h4>Interrupts Handlers</h4>
Interrupts are handled via the Interrupt Descriptor Table (IDT). The IDT describes a handler for each interrupt. The interrupts are numbered (0–255) and the handler for interrupt i is defined at the ith position in the table. There are three different kinds of handlers for interrupts:
<ul>
<li>Task handler</li>
<li>Interrupt handler</li>
<li>Trap handler</li>
</ul>
The task handlers use functionality specific to the Intel version of x86, so they won’t be covered here. The only difference between an interrupt handler and a trap handler is that the interrupt handler disables interrupts, which means you cannot get an interrupt while at the same time handling an interrupt. In this article, we will use trap handlers and disable interrupts manually when we need to.
Let’s move to the code part!
<h3>1.Creating an Entry in the IDT</h3>
An entry in the IDT for an interrupt handler consists of 64 bits. The highest 32 bits are shown in the figure below:
<pre>Bit: | 31 16 | 15 | 14 13 | 12 | 11 | 10 9 8 | 7 6 5 | 4 3 2 1 0 | Content: | offset high | P | DPL | 0 | D | 1 1 0 | 0 0 0 | reserved |</pre>
The lowest 32 bits are presented in the following figure:
<pre>Bit: | 31 16 | 15 0 | Content: | segment selector | offset low |</pre>
A description for each name can be found in the table below:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/869/1*nLfuY17w-OicLmXGVYN8vQ.png"></figure>The offset is a pointer to code (preferably an assembly code label). For example, to create an entry for a handler whose code starts at 0xDEADBEEF and that runs in privilege level 0 (therefore using the same code segment selector as the kernel) the following two bytes would be used:
<pre>0xDEAD8E00 0x0008BEEF</pre>
If the IDT is represented as an unsigned integer idt[512] then to register the above example as a handler for interrupt 0 (divide-by-zero), the following code would be used:
<pre>idt[0] = 0xDEAD8E00 idt[1] = 0x0008BEEF</pre>
<h3>2.Handling an Interrupt</h3>
When an interrupt occurs the CPU will push some information about the interrupt onto the stack, then look up the appropriate interrupt handler in the IDT and jump to it. The stack at the time of the interrupt will look like the following:
<pre>[esp + 12] eflags [esp + 8] cs [esp + 4] eip [esp] error code?</pre>
The reason for the question mark behind the error code is that not all interrupts create an error code. The specific CPU interrupts that put an error code on the stack are 8, 10, 11, 12, 13, 14, and 17. The error code can be used by the interrupt handler to get more information on what has happened. Also, note that the interrupt number is not pushed onto the stack. We can only determine what interrupt has occurred by knowing what code is executing — if the handler registered for interrupt 17 is executing, then interrupt 17 has occurred.
Once the interrupt handler is done, it uses the iret instruction to return. The instruction iret expects the stack to be the same as at the time of the interrupt (see the figure above). Therefore, any values pushed onto the stack by the interrupt handler must be popped. Before returning, iret restores eflags by popping the value from the stack and then finally jumps to cs:eip as specified by the values on the stack.
The interrupt handler has to be written in assembly code, since all registers that the interrupt handlers use must be preserved by pushing them onto the stack. This is because the code that was interrupted doesn’t know about the interrupt and will therefore expect that its registers stay the same. Writing all the logic of the interrupt handler in assembly code will be tiresome. Creating a handler in assembly code that saves the registers, calls a C function, restores the registers, and finally executes iret is a good idea!
The C handler should get the state of the registers, the state of the stack, and the number of the interrupt as arguments. The following definitions can for example be used:
<pre>struct cpu_state { unsigned int eax; unsigned int ebx; unsigned int ecx; . . . unsigned int esp; } __attribute__((packed));</pre>
<pre> struct stack_state { unsigned int error_code; unsigned int eip; unsigned int cs; unsigned int eflags; } __attribute__((packed));</pre>
<pre>void interrupt_handler(struct cpu_state cpu, struct stack_state stack, unsigned int interrupt);</pre>
<h3>3.Creating a Generic Interrupt Handler</h3>
Since the CPU does not push the interrupt number on the stack it is a little tricky to write a generic interrupt handler. This section will use macros to show how it can be done. Writing one version for each interrupt is tedious — it is better to use the macro functionality of NASM [34]. And since not all interrupts produce an error code the value 0 will be added as the “error code” for interrupts without an error code. The following code shows an example of how this can be done:
<a href="https://medium.com/media/dac918471a91a14d00dd3a06f6f41107/href">https://medium.com/media/dac918471a91a14d00dd3a06f6f41107/href</a>The common_interrupt_handler does the following:
<ul>
<li>Push the registers on the stack.</li>
<li>Call the C function interrupt_handler.</li>
<li>Pop the registers from the stack.</li>
<li>Add 8 to esp (because of the error code and the interrupt number pushed earlier).</li>
<li>Execute iret to return to the interrupted code.</li>
</ul>
Since the macros declare global labels the addresses of the interrupt handlers can be accessed from C or assembly code when creating the IDT.
<h3>4.Loading the IDT</h3>
The IDT is loaded with the lidt assembly code instruction which takes the address of the first element in the table. It is easiest to wrap this instruction and use it from C:
<a href="https://medium.com/media/1e002cb50e5145fb9e1f5e13e362e8f2/href">https://medium.com/media/1e002cb50e5145fb9e1f5e13e362e8f2/href</a><h3>4.Programmable Interrupt Controller (PIC)</h3>
To start using hardware interrupts you must first configure the Programmable Interrupt Controller (PIC). The PIC makes it possible to map signals from the hardware to interrupts. The reasons for configuring the PIC are:
<ul>
<li>Remap the interrupts. The PIC uses interrupts 0–15 for hardware interrupts by default, which conflicts with the CPU interrupts. Therefore the PIC interrupts must be remapped to another interval.</li>
<li>Select which interrupts to receive. You probably don’t want to receive interrupts from all devices since you don’t have code that handles these interrupts anyway.</li>
<li>Set up the correct mode for the PIC.</li>
</ul>
In the beginning, there was only one PIC (PIC 1) and eight interrupts. As more hardware was added, 8 interrupts were too few. The solution chosen was to chain on another PIC (PIC 2) on the first PIC (see interrupt 2 on PIC 1).
The hardware interrupts are shown in the table below:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/868/1*ZK5f9Ih7HdcNJs43nSBR-A.png"></figure>Every interrupts from the PIC has to be acknowledged — that is, sending a message to the PIC confirming that the interrupt has been handled. If this isn’t done the PIC won’t generate any more interrupts.
Acknowledging a PIC interrupt is done by sending the byte 0x20 to the PIC that raised the interrupt. Implementing a pic_acknowledge function can thus be done as follows:
<a href="https://medium.com/media/d516c0fc3455a62f31ee5a33beb500b5/href">https://medium.com/media/d516c0fc3455a62f31ee5a33beb500b5/href</a><h3>5.Reading Input from the Keyboard</h3>
The keyboard does not generate ASCII characters, it generates scan codes. A scan code represents a button — both presses and releases. The scan code representing the just pressed button can be read from the keyboard’s data I/O port which has an address 0x60. How this can be done is shown in the following example:
<a href="https://medium.com/media/97e201dea63ae977423a065662342996/href">https://medium.com/media/97e201dea63ae977423a065662342996/href</a>The next step is to write a function that translates a scan code to the corresponding ASCII character. If you want to map the scan codes to ASCII characters as is done on an American keyboard then Andries Brouwer has a great tutorial.
Remember, since the keyboard interrupt is raised by the PIC, you must call pic_acknowledge at the end of the keyboard interrupt handler. Also, the keyboard will not send you any more interruptions until you read the scan code from the keyboard.
If all is working fine, Keyboard input appear in com1.out file.
Well done! you just successfully handle interrupts and inputs. The completed OS from my Github is <a href="https://github.com/imashaWe/noxOS">here</a>. We will meet the next article Implement Your Own Operating System (Part 06).
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
Thank you!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=2afdc0d1f8df" width="1" height="1" alt="">

Implement Your Own Operating System (Part 05)

<figure><img alt="" src="https://cdn-images-1.medium.com/max/640/1*0SF0bkZUdi0Psxdmcr3e1g.jpeg"></figure>In this article, we will discuss Segmentation. Segmentation means accessing the memory through segments. Segments are portions of the address space, possibly overlapping, specified by a base address and a limit. To address a byte in segmented memory, you use a 48-bit logical address: 16 bits that specify the segment and 32-bits that specify what offset you want within that segment. The offset is added to the base address of the segment, and the resulting linear address is checked against the segment’s limit — see the figure below. If everything works out fine (including access-rights checks ignored for now) the result is a linear address. When paging is disabled, then the linear address space is mapped 1:1 onto the physical address space, and the physical memory can be accessed.
<h4>Translation of logical addresses to linear addresses.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/600/1*sZqElgjyEcSwGpvCb4Ua2A.png"></figure>To enable segmentation you need to set up a table that describes each segment — a segment descriptor table. In x86, there are two types of descriptor tables: the Global Descriptor Table (GDT) and Local Descriptor Tables (LDT). An LDT is set up and managed by user-space processes, and all processes have their own LDT. LDTs can be used if a more complex segmentation model is desired — we won’t use it. The GDT is shared by everyone — it’s global.
As we discuss in the virtual memory and paging sections, segmentation is rarely used more than in a minimal setup, similar to what we do below in the coding part.
Ok, Let’s move to the code!
<h3>1.Accessing Memory</h3>
Most of the time when accessing memory there is no need to explicitly specify the segment to use. The processor has six 16-bit segment registers: cs, ss, ds, es, gs and fs. The register cs is the code segment register and specifies the segment to use when fetching instructions. The register ss is used whenever accessing the stack (through the stack pointer esp), and ds is used for other data accesses. The OS is free to use the registers es, gs and fs however, it wants.
Below is an example showing implicit use of the segment registers:
<pre>func: mov eax, [esp+4] mov ebx, [eax] add ebx, 8 mov [eax], ebx ret</pre>
The above example can be compared with the following one that makes explicit use of the segment registers:
<pre>func: mov eax, [ss:esp+4] mov ebx, [ds:eax] add ebx, 8 mov [ds:eax], ebx ret</pre>
You don’t need to use ss it for storing the stack segment selector, or ds for the data segment selector. You could store the stack segment selector in ds and vice versa. However, in order to use the implicit style shown above, you must store the segment selectors in their indented registers.
So we should make a file called gdt.s like this:
<a href="https://medium.com/media/64dafe1215303d219b289a9a67c31e74/href">https://medium.com/media/64dafe1215303d219b289a9a67c31e74/href</a>Don’t forget to add gdt.o file to Makefile .
<h3>2.Loading the Global Descriptor Table (GDT):</h3>
<h4>The Global Descriptor Table (GDT)</h4>
A GDT/LDT is an array of 8-byte segment descriptors. The first descriptor in the GDT is always a null descriptor and can never be used to access memory. At least two segment descriptors (plus the null descriptor) are needed for the GDT because the descriptor contains more information than just the base and limit fields. The two most relevant fields for us are the Type field and the Descriptor Privilege Level (DPL) field.
Table 3–1 in chapter 3 of the Intel manual [33] specifies the values for the Type field. The table shows that the Type field can’t be both writable and executable at the same time. Therefore, two segments are needed: one segment for executing code to put in cs (Type is Execute-only or Execute-Read) and one segment for reading and writing data (Type is Read/Write) to put in the other segment registers.
The DPL specifies the privilege levels required to use the segment. x86 allows for four privilege levels (PL), 0 to 3, where PL0 is the most privileged. In most operating systems (eg. Linux and Windows), only PL0 and PL3 are used. However, some operating systems, such as MINIX, make use of all levels. The kernel should be able to do anything, therefore it uses segments with DPL set to 0 (also called kernel mode). The current privilege level (CPL) is determined by the segment selector in cs.
The segments needed are described in the table below.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/576/1*3BUrwbhp2AaS1Lz_NmlgGg.png"></figure>Loading the GDT into the processor is done with the lgdt assembly code instruction, which takes the address of a struct that specifies the start and size of the GDT. It is easiest to encode this information using a <a href="https://littleosbook.github.io/#packing-structs">“packed struct”</a> as shown in the following example:
<pre>struct gdt { unsigned int address; unsigned short size; } __attribute__((packed));</pre>
If the content of the eax the register is the address to such a struct, then the GDT can be loaded with the assembly code shown below:
<pre>lgdt [eax]</pre>
It might be easier if you make this instruction available from C, the same way as was done with the assembly code instructions in and out.
After the GDT has been loaded the segment registers need to be loaded with their corresponding segment selectors. The content of a segment selector is described in the figure and table below:
<pre>Bit: | 15 3 | 2 | 1 0 | Content: | offset (index) | ti | rpl |</pre>
Finally, we should create the following two files to Loading the GDT:
<a href="https://medium.com/media/be6093de8d7fb086118e8e378b4a8b77/href">https://medium.com/media/be6093de8d7fb086118e8e378b4a8b77/href</a>Then we can call sgments_install_gdt function from our kmain.c :
<a href="https://medium.com/media/815e912d0db40986ace0ee4aa0efc88d/href">https://medium.com/media/815e912d0db40986ace0ee4aa0efc88d/href</a>After All, are working fine you can see the following output in os terminal:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/722/1*h9TjOZI4_Y8pMeBpjAzWrg.png"></figure>Well done! you just successfully integrated segmentation. The completed OS from my Github is <a href="https://github.com/imashaWe/noxOS">here</a>. We will meet the next article Implement Your Own Operating System (Part 05).
Reference: <a href="https://littleosbook.github.io/">The Little OS Book</a>
Thank you!
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a9550677a1cf" width="1" height="1" alt="">

Hey! I’m Imasha

Technical Skills:

Meet exciting solutions

Mobile Solutions

Web Solutions

Cloud Solutions

AI Solutions

Why customers love us

MHC Online Radio

Learning Management System

Family Live Spots

Scratch

Place App

Chat App

Articles to gain knowledge