Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the difference between uclinux and linux". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the difference between uclinux and linux".

Differences: 1, uclinux uses memory paging management, linux uses virtual memory management; 2, uclinux has no fork system call, uses vfork, and linux uses fork system call; 3, uclinux can not run when the process stack can be increased, linux can increase the process stack at run time.

The operating environment of this tutorial: linux7.3 system, Dell G3 computer.

What's the difference between uclinux and linux?

In the English word uClinux, u means Micro, small means small, and C means Control, meaning control.

So uClinux is Micro-Control-Linux, which literally means "Linux system designed for the field of microcontrol".

The difference between ucLinux and linux

No virtual storage management

Cannot add process stack when it is not running

Paging is not supported

The executable program is not elf, but flat

You can't use fork, but vfork.

RAMDISK

UClinux is an embedded linux operating system aimed at the control field. It is derived from the kernel of Linux 2.0 Linux and inherits most of the features of the mainstream Linux.

Suitable for microprocessors / microcontrollers without memory management unit (MMU). The lack of MMU support is the basic difference between uClinux and mainstream Linux.

For uCLinux, it is designed for processors without MMU and cannot use the processor's virtual memory management technology. UCLinux still uses the paging management of the memory, and the system paging the actual memory at startup. The program loads pages when the application is loaded. However, because there is no MMU management, uCLinux actually adopts the real memory management strategy.

The access to memory of uCLinux system is direct, and the addresses accessed in all programs are the actual physical addresses. The operating system does not protect the memory space, and each process actually shares a running space. Before a process is executed, the system must allocate enough contiguous address space for the process, and then load it all into the contiguous space of the main memory.

Operations without memory protection (Memory Protection) can result in the following results:

Even if an invalid pointer is called by an unprivileged process, it can trigger an address error, potentially cause the program to crash, and even cause the system to hang. Obviously, code running on such a system must be carefully programmed and tested in depth to ensure robustness and security.

For ordinary Linux, different user programs need to be run. If there is no memory protection, the security and availability of the system will be greatly reduced. However, for the embedded uClinux system, because the running program is often solidified before leaving the factory, there is no hidden danger of program intrusion that endangers the security of the system, so as long as the application program is tested completely, the probability of problems can be controlled within a limited range.

The lack of virtual memory (Virtual Memory) mainly leads to the following consequences:

First, processes loaded by the kernel must be able to run independently, regardless of their location in memory. The first way to achieve this is to "fix" the base address of the program once it is loaded into RAM; the other is to generate code that uses only relative addressing (called location-independent code, Position Independent Code, or PIC). UClinux supports both modes.

Secondly, the problem of memory allocation and release in the flat (flat) memory model should be solved. Very dynamic memory allocation can cause memory fragmentation and may deplete the system's resources. One way to enhance robustness for applications that use dynamic memory allocation is to replace the malloc () call with a pre-allocated buffer pool (Preallocated buffer pool).

Because virtual memory is not used in uclinux, page swapping in and out of memory is not implemented, because there is no guarantee that pages will be loaded to the same location in RAM. On ordinary computers, the operating system allows applications to use more memory space than physical memory (RAM), often by setting up swap partitions on the hard disk. However, in embedded systems, FLASH memory is usually used instead of hard disk, so it is difficult to access memory page exchange efficiently. Therefore, the running applications are limited to no more than the RAM space of the system.

Multitasking is not affected. Which old-fashioned network daemons (daemon) that are widely used by fork () do need to be modified. Because the child process runs in the same address space as the parent process, in some cases, the behavior of the two processes needs to be modified.

Many modern programs rely on child processes to perform basic tasks, so that the system can maintain an "interactive" state even when the process is heavily loaded, and these programs may need substantial modifications to accomplish the same task under uClinux. If a critical application relies heavily on such a structure, it will have to be rewritten.

Suppose you have a simple network daemon (daemon) that makes heavy use of fork (). The daemon director listens to a well-known port (or socket) waiting for a network client to connect. When the client connects, the daemon gives it a new connection information (the new socket number) and calls fork (). The child process then connects to the client on the new socket, while the parent process is released and can continue to listen for the new connection.

UClinux has neither an auto-growing stack nor a brk () function, so user-space programs must use the mmap () command to allocate memory. For convenience, malloc () implemented in uclinux's C language library is essentially a mmap (). At compile time, you can specify the stack size of the program.

Finally, the uClinux target board processor lacks the hardware unit of memory management, so the system interface of Linux needs to be changed. Probably the biggest difference is that there are no fork () and brk () system calls. Calling fork () copies out the process to create a child process. Under Linux, fork () is implemented using a copy-on-write page. Without MMU, uclinux cannot copy a process completely and *, nor does it have access to copy-on-write. To make up for this, uClinux implements vfork (). When the parent process calls vfork () to create the child process, the two processes share all their memory space, including the stack. The child process either executes instead of the parent process (when the parent process is already sleep) until the child process calls exitI () to exit, or calls exec () to execute a new process, which results in the loading of the executable file. Even if this process is only a copy of the parent process, this process cannot be avoided. When the child process executes exit () or exec (), the child process wakes up the parent process using wakeup, and the parent process continues to execute.

Kernel changes to the common architecture:

In the release of uCLinux, the / linux/mmnommu directory replaced the / linux/mm directory. The former is that the modified memory management subsystem is modified, which removes the hardware dependence of MMU and provides basic internal management functions in the kernel software itself.

Many subsystems need to be modified, added, or rewritten. Kernel and user memory allocation and release processes must be reimplemented, and support for transparent interaction / page scheduling has been removed. In the kernel, a program support module supporting kernel independent code (PIC) is added, and a new binary object code format, called flat format, is used to support PIC (with a very compact header).

The kernel also provides a program loading module that supports ELF format to support executable programs using fixed base addresses. The two modes have their own advantages and disadvantages. The traditional PIC runs fast and the code is compact, but the code size is limited. For example, the 16-bit relative jump of Motorola 68K architecture limits the size of PIC programs to 32KB, while the program code listed by the method of fixed benchmark address at run time has no size limit, but it leads to more system overhead when Chen Xu is loaded by the kernel. For kernel developers, uCLinux is basically no different from Linux, the only difference is that they cannot take advantage of the memory management provided by MMU. In fact, this has no effect on the kernel. All standard executable formats under Linux are not supported in uCLinux because these formats also use some functions of virtual memory. UCLinux uses another flat format. The flat format is a concise and efficient executable file format whose values contain executable code and data, as well as some relocatable information needed to load the executable file into any location in memory.

Summary: in the process of porting applications to uClinux and writing our own code, we will always focus on these features:

1. In configure, select-disable-shared and-enable-static when configure is needed if possible.

2. Change all fork () that appears in the source code to vfork ()

3. Add-Wl,-elf2flt to the cross compiler and compilation options and link options in Makefile. Although this is only a link option, I carefully specify it in LDFLAGS and CFLAGS, and even in CC.

Thank you for your reading, the above is the content of "what is the difference between uclinux and linux". After the study of this article, I believe you have a deeper understanding of the difference between uclinux and linux, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.