Pkzd process design policy 1: pkzd Process Policy

Pkzd process design policy 1: pkzd Process Policy

First, for any operating system, the system kernel must specify a way to obtain process information. pkzd uses a Global Array struct proc [NPROC].

Here, struct proc is the structure of the process structure, and NPROC is a macro used to determine the maximum number of processes that can coexist currently. The code of the struct proc structure is as follows:

 1 struct proc{ 2         int     p_exit; 3         uint    p_stat; 4         uint    p_flag; 5         uint    p_sig; 6         uint    p_esp; 7         uint    p_lesp; 8         pid_t   p_pid; 9         pid_t   p_ppid;10         pid_t   p_pgrp;11         uid_t   p_uid;12         uid_t   p_ruid;13         gid_t   p_gid;14         gid_t   p_rgid;15         uint    p_cpu;16         int     p_pri;17         int     p_nice;18         time_t  p_time;19         uint    p_error;20         uint    *p_stack;21         uint    *p_pgdir;22         void    *p_wchan;23         void    *p_ttyp;24         int     p_signal[NSIG];25         void    *p_cdir;26         void    *p_rdir;27         uint    p_start;28         uint    p_end;29         uint    p_brk;30         uint    p_send;31         void    *p_ofile[NOFILE];32 };

　　

Operating system processes have various information, such as process id and opened file information. Some information is not required for the kernel, while others are required.

Take the process id and file descriptor table as an example to compare:

• P_pid, as the unique identifier of each process, must remain in the system kernel space. If it is designed to be placed in the user space, the pid of the process may be swapped out to the swap space, once so, the kernel cannot identify the process.
• P_ofile is the file descriptor table opened by the process. In theory, the file descriptor table of each process does not need to be resident in the kernel space. The reason is that only the current process reads and writes files. A non-running process does not read files.
• There are many reasons for the process id to have a kernel space. For example: for example, after the exit system is called by the current process, the kernel sends a signal to the parent process of the current process or wakes up the parent process waiting for the termination of the child process, if the p_pid of the parent process has been replaced, the kernel will be at a loss.

 

Pkzd stores all information about the process in struct proc, instead of distinguishing whether the information is required to be resident in the kernel (this is a lazy approach ).
The general design of unix systems puts only information useful to the current process (such as the file descriptor table) in the user space, which is generally called the u zone. The most important reason for designing the u-zone is to save memory, and today's machines have ample memory, therefore, we do not need to explicitly put all the information that can be placed in the u zone.
It directly saves the implementation of the u zone, of course, this is a lazy.
Finally, pkzd uses c. The reason why c is used rather than other languages is that c is highly compatible with assembly (c can call assembly functions, and c can be called in assembly ). The most important reason is that c has powerful control over resources, but the general object-oriented language cannot. In addition, the reason for using c is not because many people understand that c can manipulate hardware (generally, the hardware code is still compiled, although there are examples of using c ), the root cause is that c won't automatically allocate memory like java in an object-oriented language, leading to the out-of-control of resources on the operating system kernel (personal opinions on system writing ).

Link to the source code of the operating system I wrote: https://sourceforge.net/projects/pkzd/