Shulou(Shulou.com)06/02 Report--

For more information, please visit my CU blog

All of a sudden, three months have passed, and I haven't written anything in three months. I've written a lot of code in the past three months. It's time to talk about lmos. This will be the fourth development version of lmos. This year's three months are over, and there are only nine months left. Time-strapped children should hurry up. In fact, it takes enough time to develop the operating system kernel. The more time the better, but it is often not as good as I want. There is always not enough time.

Let's start with what are the new features of the fourth development version of lmos.

1. From this release, lmos no longer supports 32-bit x86 architecture, but supports a slightly more advanced 64-bit x86 architecture, which is called AMD64.

2. This version of lmos begins to have virtual memory. It's very complicated to talk about, so we'll talk about it later.

3. Lmos starts from this version and supports booting from USB flash drive. Of course, there is a premise that your computer motherboard must support slave U

USB media such as disks guide your computer, which is convenient for friends who want to verify and tamper with lmos on the physical machine.

The reason why lmos suddenly changed from 32-bit to full 64-bit is that my development of virtual memory manager is severely limited under 32-bit. Later, I think that if we want to support 64-bit in the future, it would be better to do so as soon as possible to avoid trouble in the future. In fact, the memory capacity of physical machines now exceeds that of 4GB. The x86 Mel 64 architecture was first defined by AMD, which is why it is called AMD64. When implementing the AMD64 architecture, their engineers are required to ensure that the original 32-bit os and app can run on the AMD64 architecture without any modification. A 64-bit OS can execute an unmodified 32-bit app. Under these guarantees, x86 should be improved as much as possible. You have to marvel at how great and painful x86 engineers are, hehe. In fact, the AMD64 architecture has been changed quite well. Segment almost does not work, the role of TSS has also changed, the interrupt stack is also more standardized, registers all 64-bit and a lot more registers, it seems that they also know that x86 registers are too few, page table is also 4 layers, support 4KB 2MB 1GB page size. LMOS is a full 64-bit kernel, but also requires applications and drivers to be 64-bit. LMOS will not be compatible with 32-bit programs. Although the register of AMD64 is 64-bit, it does not mean that it can access all the physical addresses between 0~0xffffffffffffffff. In fact, there are only 48 address lines or less on the CPU of the current AMD64 architecture. So how does it do it? it requires 64-bit registers to be extended with symbolic bits starting with 48 bits, which means that CPU can only access the addresses of these two intervals: 0~0x00007fffffffffff and

0xffff800000000000~0xffffffffffffffff, if you access the address between 0x800000000000~0xffff800000000000 CPU will generate an exception. But this implementation is very good for future expansion. I have a picture here that you can take a look at:

This change confirms the portability of LMOS, because the LMOS kernel has the concept of a hardware abstraction layer. It only took me a few weeks to write a 64-bit hardware abstraction layer, and then link this layer to the upper hardware-independent layer. In other words, I'm going to port LMOS to the ARM architecture by writing a hardware abstraction layer of ARM with a few changes, which makes it possible for lmos to become a general-purpose operating system.

Let's take a look at lmos's virtual memory manager in this version. Virtual memory operating system theory books only spend a little space to introduce so a little bit, in practice, virtual memory is the top priority, it can be described as the kernel of the operating system kernel. First, take a look at the general frame diagram of the virtual memory manager in this version of LMOS. My drawing is very simple. Let's take a look at it:

Let me give you an example of why virtual memory management is the kernel of the kernel. For example, if the operating system wants to describe a thread, then it must define a data structure to represent a thread. I really understand now that the previous sentence in the C language book: "Program = data structure + algorithm". This indicates that the data structure of the thread can only work if there is a real instance in memory. The kernel needs a lot of instances of this data structure to support multithreading. For example, there may be 2000 threads, and you can't statically define 2000 arrays of this data structure, so it does work. But using memory this way is too inefficient and unintelligent, because it is possible that sometimes there are only two or three threads in the system, and memory is wasted. If sometimes there are more than 2000 threads in the system, There's nothing you can do about it. There are a lot of similar data structure systems, usually between a few 10 bytes, a few 100 bytes and a 1KB. Since it is not static, we can only use a dynamic method, that is, allocate and initialize an instance of the data structure when you want to use it, and release the memory space occupied by the instance when you don't want to. This version of LMOS reimplements a more advanced memory pool to deal with this problem, first of all, the data structure is only 10 bytes, a few hundred bytes to 1KB. You can't assign one page at a time. It's called waste. Memory pools are designed to solve this problem.

Modern operating systems all seem to have concepts of protection and security. How do these concepts come true? CPU provides some mechanisms. Some of the key instructions are defined as privileged instructions, and the memory access addresses that appear in the program are defined as virtual addresses. Only after being mapped by the address mapping unit can the real physical memory be accessed. These two mechanisms form the cornerstone of writing a modern operating system. This allows each process to have a separate address space, which can be divided into user space and kernel space because of different powers. In this way, a concept of "protection" is formed. Here is a diagram of how these concepts are used in lmos:

From the above, we can only access the addresses of two intervals under x86 Murray 64, since the hardware is implemented in this way, and this implementation is conducive to expansion, then I have nothing to change. The virtual address interval of 0~0x00007fffffffffff is the user space of the process, which is private to each process, and cannot be accessed by other processes, and the virtual memory manager allocates and maps physical memory in this interval. The virtual address range of 0xffff800000000000~0xffffffffffffffff is the LMOS kernel space, which is shared by all processes, and it seems to be the only way to do this on x86. there is no other choice. I have tried many other space allocation methods that do not work. It can only be like the picture above.

LMOS this version supports USB disk boot, in order to allow more people to tamper with and verify the LMOS kernel on the physical machine, I rewrote the bootstrap of the lmos kernel this time so that I can boot lmos from the USB disk, and people can more believe that LMOS is a real thing. U disk does not need to be very large, 32MB is fine, but please back up the data in your U disk before using it. LMOS deletes all data on the flash drive. If you want to make trouble, please insert the USB disk under the linux, and then go to the / dev directory to check the device file name of your USB disk, which may be such a name as sd (x). The X in parentheses is changeable. If you have two hard drives, you will see the device file name: sda, sdb, such as the device file name in the / dev directory. When you insert the USB disk, you will see the sdc. After you find and confirm that it is the device file name of the USB disk. Under the terminal, change to the directory where you put the lmos kernel file, and execute sudo make U_DSK=/dev/sdb, (under my linux, my USB device file name is sdb, so you can do this. If you are not or are not sure, do not execute the above command), otherwise, I will not be responsible for any data loss.

Install in the virtual machine, I recommend that you use this method, so that you do not need another empty USB disk, nor do you need your host operating system is LINUX. First of all, make sure that the Oracle VM VirtualBox virtual machine software is installed in your host operating system. If you are not asked to download the relevant operating system version of Oracle VM VirtualBox and safe. After installation, first create a new virtual machine, and then download (click here to download) the virtual machine hard disk image provided by me. And mount on the virtual machine, start the virtual machine to run LMOS. This time I also provided a hard disk image in VMDK format. Convenient for friends who use the VM virtual machine.

Finally, with regard to this shell, I provide a few very simple commands:

R restart the computer as follows

T check the number of processes and threads inside the lmos as follows

M View the usage of the computer's physical memory as follows

P View the pci bus and devices inside the computer as follows

Download LMOS kernel image package

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.