首先對于任何一個操作系統, 系統內核必須應該明確一種獲取進程信息的辦法, pkzd所使用的是一個全局數組struct PRoc proc[NPROC]。

其中struct proc為進程結構的結構體, NPROC是一個用來確定當前能同時存在的進程的最大數目的宏。struct proc結構的具體代碼如下:

 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 };

　　操作系統的進程有各種各樣的信息, 比如進程id, 打開的文件信息等。有的信息對內核而言不是必須的，而有的則是必須的。

我以進程id和文件描述符表為例做個對比:

• 　　p_pid作為每個進程的唯一標識必須一直常駐在系統內核空間，如果設計時將其放在用戶空間，那么就會存在進程的pid可能被換出到交換空間的情況，一旦如此那么內核將無法辨別進程。
• 　　p_ofile為進程打開的文件描述符表, 每個進程的文件描述符表理論上不需要常駐內核空間。理由是只有當前進程才會去讀寫文件, 一個沒有運行的進程是不會存在讀取文件的情況的。
• 　　進程id必須存在內核空間的理由有很多，我舉一個例子：比如當前進程執行exit系統調用后內核要向當前進程的父進程發送一個信號或者喚醒正在等待子進程終止的父進程, 而如果此時父進程的p_pid已經被換出, 那么內核將無所適從。

　　pkzd將進程的所有信息都存放在struct proc中，而不去區分信息是否必要常駐內核（這是一種偷懶的方式）。　　unix系統的一般設計都會將只對當前進程有用的信息(比如文件描述符表)放在用戶空間中, 這個空間一般稱為u區。設計u區的最重要的理由是為了節省內存, 而現如今的機器已經都有非常充裕的內存了，所以已經不需要特別明確的把所有可以放在u區的信息都放在u區，我的做法更是直接省去了u區的實現，當然這是偷懶的。　　最后pkzd所使用的語言為c，之所以采用c而非其他語言，首先c和匯編的契合度很高（c中可以調用匯編函數，匯編中又可調用c)。最重要的理由是c對資源的有力控制，而一般的面向對象的語言并不能做到。另外使用c的理由并非是因為很多人理解的c能操控硬件（一般控制硬件的代碼還是用匯編完成的，雖然也有使用c的例子），根本的理由是c不會像java這樣的面向對象的語言肆意的自動分配內存而導致操作系統內核對資源的失控（個人編寫系統后的見解）。

　　我編寫的操作系統的源代碼的鏈接:https://sourceforge.net/projects/pkzd/