Linux core-Linux Process-general Linux technology-Linux programming and kernel information. The following is a detailed description. This chapter focuses on how to create, manage, and delete processes in the Linux kernel.
A process executes a specific task in the operating system. Programs are static entities stored on disks that contain executable machine commands and data. A process or task is an active computer program.
A process is an entity that constantly changes with the execution process. Like programs that contain commands and data, processes also contain program counters and the values of all CPU registers, at the same time, its stack stores temporary data such as subroutine parameters, return addresses, and variables. The current execution program, or process, contains the activity status in the current processor. Linux is a multi-processing operating system. Processes have independent permissions and responsibilities. If a process crashes in the system, it does not affect other processes. Each process runs in its own virtual address space and can communicate with each other only through a reliable communication mechanism under core control.
The process will use system resources during its life cycle. It uses the CPU in the system to execute commands and place commands and data in the physical memory. Use the functions provided by the file system to open and use files, and directly or indirectly use physical devices. Linux must track every process and resource in the system to achieve fair resource allocation between processes. If a process occupies most of the physical memory or CPU usage, this is unfair to other processes in the system.
The most valuable resource in the system is the CPU, which usually has only one CPU. Linux is a multi-processing operating system. Its ultimate goal is to execute tasks on every CPU in the system at any time, thus improving the CPU utilization. If the number of processes exceeds the number of CPUs, some processes must wait until the CPU is idle. The idea of multi-processing is simple. When a process requires a system resource, it will stop running and wait until the resource is available. In a single processing system, such as DOS, the CPU will be in the air and the time will be wasted. In a multi-processing system, because multiple processes can exist at the same time, when a process starts to wait, the operating system will take control of the CPU and hand it over to other processes that can run. The scheduler is responsible for selecting appropriate processes to run. in Linux, some scheduling policies are used to ensure the fairness of CPU allocation.
Linux supports multiple types of executable file formats, such as ELF and JAVA. Since these processes must use the system shared libraries, they must be transparent in management.
4.1 Linux Process
To allow Linux to manage processes in the system, each process is represented by a task_struct data structure (tasks and processes can be mixed in Linux ). The array task contains pointers to all task_struct structures in the system.
This means that the maximum number of processes in the system is limited by the size of the task array. The default value is generally 512. When a new process is created, Linux allocates a task_struct structure from the system memory and adds it to the task array. The structure of the currently running process is indicated by the current pointer.
Linux also supports real-time processes. These processes must quickly respond to external time (which means "real-time") and the system will treat these processes and other processes separately. Although task_struct has a large and complex data structure, it can be divided into some functional components:
State
The state of a process is changed according to the environment during execution. The Linux Process has the following statuses:
Running
The process is running (it is the current process of the system) or ready to run (it is waiting for the system to allocate CPU to it ).
Waiting
A process is waiting for an event or resource. In Linux, the waiting process is divided into two types: resumable and non-disruptive. A process that can be interrupted by signals. A process that can be interrupted can be waited directly under hardware conditions and cannot be interrupted under any circumstances.
Stopped
The process is stopped, usually by receiving a signal. The process being debugged may be stopped.
Zombie
This is a process terminated for some reason, but the task_struct structure is retained in the task data. It is like a dead process.
Scheduling Information
The scheduler needs this information to determine which process in the system is most urgent.
Identifiers
Each process in the system has a process flag. The process flag is not an index of the task array. It is just a number. Each process also has a user and group sign that controls the process's access to files and devices in the system.
Inter-Process Communication
Linux supports classic Unix IPC Mechanisms, such as signals, pipelines and traffic signals, and IPC Mechanisms in System V, including shared memory, traffic signals, and message queues. We will discuss in detail the IPC Mechanism in Linux in the IPC chapter.
Links
All processes in Linux are interrelated. All processes except the initialization process have a parent process. The new process is not created, but copied, or cloned from the previous process. The task_struct structure corresponding to each process contains pointers to its parent process, sibling process (with the same parent process), and child process. We can use the pstree command to observe the relationship between running processes in Linux:
In addition, all processes in the system are connected with a two-way linked list, and their root is the task_struct data structure of the init process. This linked list is used by the Linux core to find all processes in the system. It supports ps or kill commands.
Times and Timers
The core needs to record the Process Creation Time and the CPU time consumed during its lifecycle. Every time the clock beats, the core needs to update and save it in the jiffies variable to record the time consumed by the process in system and user mode. Linux supports interval timers related to processes. A process can be called by the system to set a timer so that a signal can be sent to it after the timer arrives. These timers can be one-time or periodic.
File system
The process can open or close the file freely. The task_struct structure of the process contains a pointer pointing to each open file descriptor and a pointer pointing to two VFS inode. Each VFS inode uniquely identifies a directory or file in the file and provides a unified interface for the underlying file system. Linux's support for the file system will be detailed in the filesystem chapter. These two pointers point to the root directory of the process and the other to its current or pwd directory. Pwd is derived from the Unix Command pwd to display the current working directory. The two VFS inode contain a count field. When multiple processes reference them, the value increases. This is why you cannot delete the current directory of the process or its subdirectories.
Virtual memory
Most processes have some virtual memory (not the Core Thread and background process). The Linux core must track the ing between the virtual memory and the physical memory of the system.
Processor Specific Context
Processes can be considered as the sum of the current states of the system. When a process is running, it uses the registers and stacks of the processor. When a process is suspended, the context of the process-all CPU-related statuses must be stored in its task_struct structure. When the scheduler re-schedules the process, all contexts are reset.
4.2 Identifiers
Like other Unix systems, Linux uses user and group identifiers to check access to files and executable images in the system. All files in Linux have the owner and permitted permissions. These permissions describe the user's right to use files or directories. The basic permissions are read, write, and executable. These permissions are assigned to three types of users: the owner of the file, the processes belonging to the same group, and all processes in the system. Each type of user has different permissions. For example, a file allows its owner to read and write data, but the same group can only read data and other processes cannot access the file.
Linux uses a group to grant access privileges to files and directories to a group of users, rather than a single user or all processes in the system. For example, you can create a group for all users in a software project and set its permissions to allow only users to read and write the source code in the project. A process can belong to multiple groups at the same time (up to 32). These groups are all placed in the group array in the task_struct of the process. As long as a group of processes can access a file, the process derived from this group has access permissions to the file.
The task_struct structure has four pairs of processes and group identifiers:
Uid, gid
Indicates the User Identifier and Group Identifier of the running process.
Valid uid and gid
Some programs can change the uid and gid of the execution process to the uid and gid of the program itself during execution (stored in the VFS inode attribute of the descriptive executable image ). These programs are called setuid programs and are often used to strictly control access to certain services, especially those running for other processes, such as network background processes. Valid uid and gid are the uid and gid generated when the execution of the setuid is executed. When a process attempts to access privileged data or code, the core checks the valid gid and uid of the process.
File system uid and gid
They are similar to valid uid and gid, but are used to verify the file system access permissions of processes. For example, when an NFS server running in user mode accesses a file, the NFS file system uses these flags. In this example, only the uid and gid of the file system are changed (instead of the valid uid and gid ). This prevents malicious users from sending KILL signals to the NFS server.
Saved uid and gid
POSIX standards require the implementation of these two flags, which are used by programs that change the uid and gid of processes through system calls. When the original uid and gid of the process change, they are used to save the real uid and gid.
4.3 Scheduling
All processes run in user mode in part of time and in system mode in part of time. The underlying hardware implementation varies depending on how these modes are supported, but there is a security mechanism that enables them to switch back and forth between the user mode and the system mode. The permissions in user mode are much smaller than those in system mode. The process switches to the system mode to continue execution. At this time, the core is the process. In Linux, processes cannot be preemptible. As long as they can be run, they cannot be stopped. When a process waits for a system event, it decides to release the CPU. For example, a process may need to read characters from a file. Generally, the waiting process is in the system mode when the system call occurs. The waiting process is suspended and other processes are selected by the scheduling manager for execution.
Processes often need to wait for execution of system calls. Because a process in the waiting state may also take up CPU time, Linux adopts a preload scheduling policy. In this policy, each process can only run for a short period of time: 200 milliseconds. When this time is used up, the system selects another process to run, the original process must wait for a while to continue running. This period is called a time slice.
The scheduler must select the process that is most urgent to run and can be executed.
A running process is a process that only waits for CPU resources. Linux uses a simple priority-based scheduling algorithm to select the next running process. After a new process is selected, the system must save the status of the current process, registers in the processor, and context status to the task_struct structure. At the same time, it will reset the status of the new process and give control of the system to the process. To reasonably allocate the CPU time to every executable process in the system, the scheduling manager must also save the time information in task_struct.
Policy
The scheduling policy applied to the process. There are two types of Linux processes in the system: Common and real-time processes. The priority of real-time processes is higher than that of other processes. If a real-time process is executable, it is executed first. Real-time processes have two strategies: time slice rotation and first-in-first-out. In the time slice rotation policy, each executable real-time process executes one time slice in turn, while the first-in-first-out policy executes each executable process in the order of the running queue and the sequence cannot be changed.
Priority
The priority that the scheduling Manager assigns to the process. Jiffies ). The system calls renice to change the priority of a process.
Rt_priority
Linux supports real-time processes with a higher priority than non-real-time processes. The scheduler uses this domain to give each real-time process a relative priority. You can also change the priority of real-time processes through system calls.
Counter
The time that the process allows to run (stored in jiffies ). The value of the process priority when the process is running for the first time, which decreases with time.
The core calls the scheduling manager in several locations. For example, when the current process is put into the waiting queue for running or the system call ends, and the user mode is returned from the system mode. At this time, the system clock sets the counter value of the current process to 0 to drive the scheduling manager. Each time the scheduling Manager runs, the following operations are performed:
Kernel work
The scheduling Manager runs the underlying processing program and processes the scheduling task queue. The kernel chapter describes this lightweight Core Thread in detail.
Current process
The current process must be processed before other processes are selected to run.
If the scheduling policy of the current process is time slice rotation, it is put back to the running queue.
If a task is interrupted and receives a signal from the last scheduled task, its status changes to Running.
If the current process times out, its status changes to Running.
If the current process is Running, the status remains unchanged. Processes that are neither in the Running status nor can be interrupted will be deleted from the Running queue. This means that these processes are not taken into account when the scheduling manager Selects to run processes.
Process selection
The scheduler selects a process that is most urgent to run in the running queue. If real-time processes (those with real-time scheduling policies) exist in the running queue, they have more priority values than normal processes. The normal process has a counter value, while the real-time process has a counter plus 1000. This indicates that if there are real-time processes that can run in the system, they will always run before any common process. If there are other processes with the same priority as the current process, the current running process has used some time slice, so it will be in an unfavorable situation (its counter has become smaller ); the counter value of the process with the same priority is obviously greater than that of the process, so that the process located at the top of the running queue will start to execute and the current process will be put back to the running queue. In a balance system with multiple processes of the same priority, each process is executed in sequence. This is the Round Robin policy. However, because processes often need to wait for some resources, their running sequence also changes frequently.
Swap processes
If other processes are selected to run, the current process must be suspended and a new process must be executed. Registers, physical memory, and CPU are used during process execution. Every time a subroutine is called, it places the parameters in the register and the return address in the stack, so the scheduling manager always runs in the context of the current process. Although it may be in privileged mode or core mode, it is still in the current running process. When a pending process is executed, the system's machine status, including the program counter (PC) and all processor registers, must be stored in the task_struct data structure of the process. The status of the machine that loads the new process at the same time. This process is related to the system type. Different CPUs use different methods to complete this task. Generally, this operation requires hardware assistance.
The process is switched after the scheduling manager is running. The context saved by the previous process is the same as that when the current process is loaded, including the process program counters and registers.
If the previous or current process uses virtual memory, the system must update its page table entry, which is related to the specific architecture. If the processor uses a conversion-side view buffer or a page table entry (such as Alpha AXP), the page table entry of the previous running process must be washed away.
4.3.1 Scheduling in a multi-processor system
In the Linux World, multi-CPU Systems are rare. However, Linux has done a lot of work to ensure that it can run on SMP (symmetric multiple processing) machines. Linux supports reasonable load balancing and scheduling between CPU in the system. The Load Balancing work here is more obvious than what the scheduling manager does.
In a multi-processor system, it is expected that each processor is in the overall position and working state. When the current process on the processor uses up its time slice or waits for system resources, each processor runs the scheduling manager independently. One noteworthy problem in the SMP system is that there are more than one idle process in the system. In a single processor system, the idle process is the first task in the task array. In the SMP system, each CPU has an idle process, and each CPU has a current process, the SMP system must track the idle process and the current process in each processor.
In the SMP system, the task_struct structure of each process contains the number of the processor currently running it and the number of the processor at the last run. It is meaningless to schedule processes to different CPUs for execution each time. in Linux, processor_mask can be used to make a process run only on one or more processors: If N locations, the process can run on processor N. When the scheduling manager selects a new job, it does not consider a process in which the current processor bit is not set in its processor_mask. At the same time, the scheduling manager will give some priority to the process running in this processor last time, because migrating the process to another processor causes performance loss.
4.4 files
. 1 files used by the Process
. 1 describes the information about the file system used by each process in the system. The first fs_struct contains the VFS inode pointing to the process and its shielded code. This screen code value is the default value used to create a new file and can be changed through system calls.
The second data structure, files_struct, contains information about all the files currently used by the process. The program reads from the standard input and writes it to the standard output. Any error information will be output to the standard error output. Some of these files may be real files, and some may be output/input terminals or physical devices, but programs regard them as files. Each file has a descriptive character. files_struct can contain a maximum of 256 file data structures, which respectively describe a file used by the current process. The f_mode field indicates the mode in which the file will be created: Read-only, read-write, or write-only. F_pos contains the starting position of the next file read/write operation. F_inode points to the VFS inode that describes the file, and f_ops points to an array of function entry address pointers that can be operated on the file. These abstract interfaces are powerful, allowing Linux to support multiple file types. In Linux, pipelines are implemented using the mechanism we will discuss below.
Each time a file is opened, an idle file pointer in files_struct is used to point to the new file structure. Linux processes expect that at least three file descriptors are opened when the process is started. They are standard input, standard output, and standard error output. Generally, the process inherits them from the parent process. These descriptors are used to index the fd array of the process. Therefore, standard input, standard output, and standard error output correspond to file descriptors 0, 1 and 2 respectively. Each access to a file must be completed through the file operation subroutine in the file data structure together with the VFS inode,
4.5 virtual memory
The virtual memory of a process includes executable code and multiple resource data. The first load is the program image, such as ls. Like all executable images, ls is composed of executable code and data. This image file contains all the information required to load executable code and connects program data to the virtual memory space of the process. Then, during execution, the process locates the virtual memory that can be used to include the file content being read. The newly allocated virtual memory must be connected to the virtual memory of the process. Finally, the Linux Process calls a common library process, such as a file processing subroutine. If each process has a copy of the database process, sharing becomes meaningless. In Linux, multiple processes can use the Shared Library at the same time. The code and data from the shared library must be connected to the virtual address space of the process and the virtual address space of other processes that share the database.
At any time, the process does not simultaneously use all code and data contained in its virtual memory. Although it can load the code used in specific circumstances, such as initialization or handling special events, it also uses part of the subprograms of the shared library. However, loading all the code and data that are not or rarely used into the physical memory causes a great waste. If multiple processes in the system waste so much resources, the system efficiency will be greatly reduced. Linux uses request paging technology to bring virtual memory that processes need to access into the physical memory. The core marks these virtual addresses in the process page table as existing but not in the memory, without directly calling all code and data into the physical memory. When a process tries to access the code and data, the system hardware generates page errors and transfers the control to the Linux core for processing. In this way, for each virtual memory area in the processor address space, Linux must know where the virtual memory comes from and how to load it into memory to handle page errors.
. 2 virtual memory of the process
The Linux core needs to manage all the virtual memory addresses. The content in the virtual memory of each process is described in the vm_area_struct structure pointed to in the task_struct structure. The mm_struct data structure of a process also contains information about the loaded executable image and pointers to the process page table. It also contains a pointer to the vm_area_struct linked list. Each pointer represents a virtual memory area in the process.
This linked list is arranged by virtual memory location. 2 shows the virtual memory of a simple process and its core data structure distribution chart. Because the sources of the virtual memory areas are different, Linux uses the pointer pointing to a set of virtual memory processing procedures in vm_area_struct to draw like this interface. By using this policy, all process virtual addresses can be processed in the same way, without the need to understand the differences between the underlying memory management. For example, when a process attempts to access a non-memory area, the system only needs to call the page error handling process.
When a new virtual memory area is created for a process or the processing page is not physically in memory, the Linux core reuses the vm_area_struct data structure set of the process. In this way, the time spent on finding vm_area_struct directly affects the system performance. Linux connects the vm_area_struct data structure to the AVL (Adelson-Velskii and Landis) tree structure to accelerate the speed. In this connection, each vm_area_struct structure has a left pointer and a right pointer pointing to the vm_area_struct structure. The pointer on the left points to a lower starting virtual memory address node, and the pointer on the right points to a higher starting virtual memory address node. To locate a node, Linux starts from the root node of the tree until the correct vm_area_struct structure is found. Inserting or releasing a vm_area_struct structure does not consume additional processing time.
When a process requests virtual memory allocation, Linux does not directly allocate physical memory. It only creates a vm_area_struct structure to describe the virtual memory, which is connected to the virtual memory linked list of the process. When a process tries to write the newly allocated virtual memory, the system generates a page error. The processor will try to resolve this virtual address, but if the page table entry corresponding to this virtual address cannot be found, the processor will discard the parsing and generate a page error exception, which is handled by the Linux core. In Linux, check whether the virtual address is in the virtual address space of the current process. In Linux, the correct PTE is created and a physical page is allocated to the process. The code or data contained on this page may need to be read from the file system or the swap disk. Then the process starts execution from the page error. Because the physical memory already exists, no page exception occurs.
4.6 Process Creation
When the system is started, it is always in the core mode. At this time, there is only one process: initialization process. Like all processes, the initialization process also has a machine State represented by stacks and registers. When other processes are created and run in the system, the information is stored in the task_struct structure of the initialization process. At the end of system initialization, the initialization process starts a Core Thread (init) and keeps it in the idle state. If there is nothing to do, the scheduling Manager runs the idle process. The idle process is the only process that does not dynamically allocate task_struct. Its task_struct is statically defined and named init_task during core construction.
Because it is the first real process of the system, the identifier of the init Core Thread (or process) is 1. It is responsible for completing some initialization tasks of the system (such as opening the system console and installing the root file system), and executing system initialization programs, such as/etc/init, /bin/init or/sbin/init. These initialization Programs depend on specific systems. The init program uses/etc/inittab as the script file to create a new process in the system. These new processes create their own new processes. For example, the getty process creates a login process when the user attempts to log on. All processes in the system are derived from the init Core Thread.
The new process is created by cloning the old process or the current process. The system can call fork or clone to create a new task. replication takes place in the core of the core state. At the end of the System Call, there is a new process waiting for the scheduling manager to choose it to run. The system allocates a new task_struct data structure from the physical memory and one or more physical pages containing the copied process stack (user and core. Then create a unique process identifier that marks the new task. However, it is reasonable that the duplicate process retains its parent process identifier. The newly created task_struct will be placed in the task array, and the content page table in the task_struct of the copied process will be merged into the new task_struct.
After the replication is complete, Linux allows two processes to share resources instead of copying copies. These resources include files, signal processing processes, and virtual memory. Processes use their respective count to count shared resources. Before the two processes use the resources, Linux will never release the resources. For example, if the replication process wants to share the virtual memory, its task_struct will contain a pointer to the mm_struct of the original process. Mm_struct adds the count variable to indicate the number of times the current process is shared.
The technology used by the replication process virtual space is very clever. Copy will generate a new vm_area_struct structure and the corresponding mm_struct structure, as well as the page table of the copied process. No virtual memory of the process is copied. Some of the virtual memory of a process may be in the physical memory, some may be in the executable image of the current process, and some may be in the swap file, therefore, copying is a difficult and tedious task. Linux uses a "copy on write" technology: this virtual memory block is copied only when one of the two processes perform write operations on the virtual memory. However, no matter whether writing or not, any virtual memory can be shared between two processes. Memory of read-only attributes, such as executable code, can always be shared. To make the "copy on write" policy work, the page table entries in the writable areas must be marked as read-only, and their vm_area_struct data must be set to "copy on write ". A page error occurs when one of the processes tries to write to the virtual memory. In this case, Linux copies the memory and modifies the page tables and virtual memory data structures of the two processes.
4.7 clock and Timer
The core tracks the Process Creation Time and the CPU time consumed during its lifecycle. When each clock is ticking, the core updates the time consumed by the current process in system mode and user mode (recorded in jiffies ).
In addition to the preceding notes, Linux also supports time interval timers related to several processes.
A process can use these timers to send various signals to it from time to time. These timers are as follows:
Real
This timer counts based on the real-time clock. When the clock expires, it sends a SIGALRM signal to the process.
Virtual
This timer is only used to calculate the number of running logs. When the clock expires, the SIGVTALRM signal is sent.
Profile
This timer counts when the process is running and the core is running. Send the SIGPROF signal to the process from time to time.
The preceding time interval timer can also be run independently. in Linux, all the information is stored in the task_struct data structure of the process. System calls allow you to set these time interval timers and start, terminate, or read their current values. The Virtual and Profile timers are processed in the same way.
After each tick, the timer of the current process will decrease in time interval. Then, an appropriate signal will be sent.
The Real-time interval timer mechanism is somewhat different, which will be discussed in detail in the kernel chapter. Each process has its own timer_list data structure. When the timer runs at intervals, it is discharged into the system's timer linked list. When the timer expires, the underlying processing process will delete it from the queue and call the interval processing process. This process sends a SIGALRM signal to the process, restarts the timer, and places it in the system clock queue.
4.8 Program Execution
Like Unix, Linux programs are executed through the command interpreter. The command interpreter is a user process called a shell program.
There are multiple shell programs in Linux. The most popular ones are sh, bash, and tcsh. Except for several built-in commands such as cd and pwd, the command is an executable binary file. When you type a command, the Shell program searches for the Directory contained in the path environment variable of the process to locate the executable image file. If it is found, it is loaded and executed. Shell uses the fork mechanism described above to copy itself and replace its sub-processes with the binary executable image content. Generally, shell waits for the completion of the command or the exit of the sub-process. You can press the control-Z key to switch the sub-process to the background and shell starts running again. At the same time, you can run the shell command bg in the background, and shell will send the SIGCONT signal to restart the process until the process needs terminal output and input.
The executable file can be in many formats, or even a script file. The script file needs an appropriate command interpreter to process them; for example,/bin/sh to interpret shell scripts. The executable target file contains executable code and data, so that the operating system can obtain enough information to load it to the memory and execute it. The most common target file in Linux is ELF, but in theory Linux can flexibly process almost all target file formats.
. 3 registered binary format
By using a file system, the binary format supported by Linux can be constructed to the core and loaded as a module. The core stores a supported binary format linked list (see. 3). When a file is executed, various binary formats are tried in sequence.
The most widely supported formats in Linux are a. out and ELF. The execution file does not need to be fully read into the memory, but uses a request loading technology. Each part of the executable image used by the process is transferred to the memory, and useless parts are discarded from the memory.
4.8.1 ELF
ELF (executable and connectable format) is a target file format designed by the Unix System Lab and is now the most widely used format in Linux. However, compared with other target file formats, such as ECOFF and a. out, ELF has a higher overhead, and its advantage is more flexible. The ELF executable file contains executable code, namely the body segment: text and data Segment: data. The table in the executable image describes how the program should be put into the virtual address space of the process. The static connection image is obtained through the connector ld and contains all the code and data required to run the image in a single image. This image also defines the Memory Distribution of the image and the address of the code to be executed first.
. 4. ELF Executable File Format
4. The structure of an ELF executable image with a static connection is given.
This is a simple C program that prints "Hello World" and exits. The file header is used as an ELF image with two physical file headers (e_phnum = 2). The physical file header is located 52 bytes at the start of the image file. The first physical file header describes executable code in the image. It starts from the virtual address 0x8048000 and is 65532 bytes in length. This is because it contains the printf () function library code to output a static connection image of "Hello World. The entry point of the image, that is, the first instruction of the program, is not located at the starting position of the image but at the virtual address 0x8048090 (e_entry. The code is followed by the second physical file header. This physical file header describes the data used by this program ,? ? What kind of glaze is called the aunt? The size of x8 is 2200 bytes (p_filesz) in the file but 4248 bytes in the memory. This is because the first 2200 bytes contain pre-initialization data, and the next 2048 bytes contain the data initialized by the executed code.
When Linux loads an ELF executable image to the virtual address space of the process, it does not actually load the image. First, it establishes its virtual memory data structure: vm_area_struct tree and page table of the process. What page will be generated when the program is executed? Bf9 then done ?? Too many tasks? What happens? Qingyou Qingmin Siwei) qing3 Qingmin qingting qingmei jiangyi Zhiyong Zhike disease for qingting glaze Qingmin Siwei R bad? The LF binary format loader finds that this image is a valid ELF executable image, which clears the current executable image of the process from the virtual memory. When a process is a replication image (all processes are), the parent process executes the old image program, such as a command interpreter like bash. At the same time, it will clear any signal processing process and close open files. At the end of the scouring process, the process is ready for the new executable image. Regardless of the format of the executable image, the mm_struct structure of the process stores the same information, which is a pointer to the image code and data. When the executable ELF image is read from the file and the relevant program code is mapped to the virtual address space of the process, the values of these pointers are determined. Vm_area_struct is also created, and the page table of the process is modified. The mm_struct structure also contains pointers to parameters passed to programs and process environment variables.
ELF shared library
On the other hand, the dynamic connection image does not contain all the code and data required for running. Some of them are connected to the shared library only at runtime. The ELF shared library list is also used by dynamic connectors when you connect to the shared library at runtime. Linux uses several dynamic connectors, such as ld. so.1, libc. so.1, and ld-linux.so.1, which are placed in the/lib directory. These libraries contain common code, such as C language subprograms. If there is no dynamic connection, all programs will have to copy all the database processes and connect them in. This requires more disk space and virtual memory space. Through dynamic connections, information about each referenced library process can be included in the ELF image list. This information is used to help the dynamic connector locate the library process and connect it to the address space of the program.
4.8.2 script file
The interpreter is required to run the script file. Linux has many interpreters, such as wish, perl, and command shell program tcsh. Linux uses standard Unix rules. The first line of the script file contains the name of the script interpreter. The typical script file starts with the following:
#! /Usr/bin/wish
In this case, the command interpreter will try to find the script interpreter. Then it opens the execution file of this script interpreter to get a VFS inode pointing to this file and causes this script interpreter to start interpreting this script. In this case, the script file name is changed to parameter 0 (the first parameter) of the script interpreter, and the other parameters are moved up to a position (the first parameter is changed to the second parameter ). The script interpreter is loaded in the same way as other executable files. Linux will try various binary executable formats one by one until it can be executed.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
