What is the difference between uclinux and linux

Differences: 1. Uclinux uses memory paging management, while Linux uses virtual memory management; 2. Uclinux does not have a fork system call and uses vfork, while Linux uses a fork system call; 3. Uclinux cannot increase the process stack when running , Linux can increase the process stack at runtime.

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

What is the difference between uclinux and linux

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

So uClinux is Micro-Control-Linux literally means "Linux system designed for the field of micro-control".

The difference between ucLinux and linux

• No virtual memory management

• Cannot increase the process stack while running

• Paging is not supported

• The executable program is not elf, but flat

• cannot be used fork, Instead use vfork

• ##RAMDISK

uClinux is an embedded Linux operating system for the control field. It starts from the Linux 2.0/2.4 kernel Derived from it, it inherits most of the features of mainstream Linux.

Suitable for microprocessors/microcontrollers that do not have a memory management unit (MMU). The lack of MMU support is the fundamental difference between uClinux and mainstream Linux.

For uCLinux, its design is for processors without MMU and cannot use the processor's virtual memory management technology. uCLinux still uses memory paging management, and the system pages the actual memory when it starts. The program loads in pages while the application is loading. However, since there is no MMU management, uCLinux actually adopts a real memory management strategy.

uCLinux system has direct access to memory, and the addresses accessed in all programs are 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 continuous address space for the process, and then load it all into the continuous space of the main memory.

Operations without memory protection(Memory Protection) will lead to the following results:

Even if an invalid pointer is called by an unprivileged process, an address will be triggered errors and potentially cause the program to crash or even cause the system to hang. Obviously, code running on such a system must be carefully programmed and thoroughly tested to ensure robustness and security.

For ordinary Linux, different user programs need to be run. Without memory protection, the security and reliability of the system will be greatly reduced; however, for embedded uClinux systems, due to the running programs It is often solidified before leaving the factory, and there is no hidden danger of program intrusion that harms system security. Therefore, as long as the application has undergone relatively complete testing, the probability of problems can be controlled within a limited range.

No virtual memory(Virtual Memory) mainly leads to the following consequences:

First, the processes loaded by the kernel must be able to run independently, with them in the memory The location is irrelevant. The first way to achieve this goal is to "fix" the program's base address once it is loaded into RAM; another way is to generate code that uses only relative addressing (called "position-independent code" , Position Independent Code, referred to as PIC). uClinux supports both modes.

Secondly, we need to solve the problem of memory allocation and release in the flat memory model. Very dynamic memory allocation can cause memory fragmentation and may exhaust system resources. For applications that use dynamic memory allocation, one way to increase robustness is to replace malloc() calls with a preallocated buffer pool.

Since virtual memory is not used in uclinux, page swapping in and out of memory is not implemented because there is no guarantee that the page will be loaded into the same location in RAM. On ordinary computers, the operating system allows applications to use larger memory space than physical memory (RAM), which is often achieved by setting up a swap partition on the hard disk. However, in embedded systems, FLASH memory is usually used instead of the hard disk, and it is difficult to efficiently implement memory page swap access. Therefore, the allocable space of running applications is limited to no larger than the system's RAM space.

Multi-tasking is not affected. Which old network daemons (daemons) widely use fork() do need to be modified. Since the child process runs in the same address space as the parent process, in some cases it is also necessary to modify the behavior of both processes.

Many modern programs rely on child processes to perform basic tasks so that the system can remain in an "interactive" state even when the process is heavily loaded. These programs may require substantial modifications to perform Complete the same task under uClinux. If a critical application relied heavily on such a structure, it would have to be rewritten.

Suppose there is a simple network background program (daemon) that uses fork() extensively. This daemon listens on a well-known port (or socket) and waits for network clients to connect. When the client connects, the daemon gives it new connection information (new socket number) and calls fork(). The child process will then connect to the client on the new socket, and the parent process will be released and can continue to listen for new connections.

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

Finally, the uClinux target board processor lacks a memory management hardware unit, which requires some changes to the Linux system interface. Probably the biggest difference is that there are no fork() and brk() system calls. Calling fork() copies the process out to create a child process. Under Linux, fork() is implemented using copy-on-write pages. Since there is no MMU, Uclinux cannot completely and reproducibly copy a process, and there is no access to copy-on-write. To make up for this shortcoming, uClinux implements vfork(). When the parent process calls vfork() to create a child process, the two processes share their entire memory space, including the stack. The child process either executes in place of the parent process (the parent process is already sleeping at this time) until the child process calls exitI() to exit, or calls exec() to execute a new process, at which time the executable file will be loaded. Even if the process is just a copy of the parent process, this process cannot be avoided. When the child process executes exit() or exec(), the child process uses wakeup to wake up the parent process, and the parent process continues execution.

Kernel changes in general architecture:

In the release of uCLinux, the /linux/mmnommu directory replaced the /linux/mm directory. The former is the modified memory management subsystem that has been modified and removed. It eliminates 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. The kernel and user memory allocation and release processes must be re-implemented to be transparent Interactive/paging support was also removed. In the kernel, a program support module to support "kernel-independent code (PIC)" was added, and a new binary object code format, called flat format, was used to support PIC (with very Compact header).

The kernel also provides a program loading module that supports the ELF format to support executable programs using fixed base addresses. Both modes have their own pros and cons. The traditional PIC runs fast and the code Compact, but there are code size restrictions. For example, the 16-bit relative jump of the Motorola 68K architecture limits the PIC program to no more than 32KB in size, and the program code that is listed using the method of fixed base address during runtime has no size limit, but when Chen Xu was After the kernel is loaded, it causes a lot of system overhead. For kernel developers, uCLinux is basically no different from Linux. The only difference is that the memory management provided by MMU cannot be used. In fact, this has no impact on the kernel. Everything under Linux Standard executable file formats are not supported by 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. The value contains executable code and data, as well as some relocatable information needed to load the executable file into any location in memory.

Summary: When porting the application to uClinux, as well as writing the code yourself During the process, we will always focus on these features:

1. When configuring, if possible, select —disable-shared and —enable-static.

2. Change all occurrences of fork() in the source code to vfork();

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

Recommended learning: Linux video tutorial

The above is the detailed content of What is the difference between uclinux and linux. For more information, please follow other related articles on the PHP Chinese website!