Overview of Process in MINIX3
Bài từ dự án mở SysNet Wiki.
Process là một thể hiện của chương trình lúc hoạt động trong bộ nhớ của máy tính. Mỗi chương trình sẽ được lưu trữ dưới dạng dữ liệu trong máy tính. Chương trình thực thi được phân biệt với các dữ liệu khác nhờ vào thành phần headers chứa thông tin cần thiết cho sự hoạt động của process trong bộ nhớ (code, data, stack ...).
Mục lục |
[Sửa] Cấu trúc các process trong MINIX3
Nhìn chung hệ điều hành MINIX3 chỉ gồm 2 loại process: kernel-mode process và user-mode process.
Phần kernel-mode process chỉ chứa 3 process: kernel, clock task và system task.
[Sửa] Kernel-mode process
[Sửa] Kernel process trong MINIX3
Kernel process (gọi tắt là kernel) cũng là 1 process như cać process khác trong OS, tuy nhiên do có những khác biệt nhất định với các thành phần khác cấu tạo nên OS nên kernel còn được gọi là Hardware process trong MINIX3. Kernel sẽ đảm nhận các nhiệm vụ cấp thiết như: scheduling, I/O control, IPC (interprocess communacation), sao chép vùng nhớ này sang vùng nhớ khác. Nói chung kernel sẽ làm những nhiệm vụ tương đương như giao tiếp trực tiếp với phần cứng. Các thành phần khác nếu muốn sử dụng các chức năng này phải gửi yêu cầu đến kernel.
Kernel là một process đặc biệt khi mà nó hầu như không nằm trong tình trạng "ready", không bao giờ được xem như đang "chạy". Đơn giản là vì kernel làm nhiệm vụ quyết định cho process nào chạy, quyết định dừng process khi xảy ra tình trạng block (đợi thiết bị ngoại vi), hoặc sử dụng hết thời gian chạy, hoặc có interrupt xảy ra trong quá trình chạy. 1 process muốn sử dụng các chức năng của kernel sẽ phải chuyển quyền điều khiển cho kernel, nhưng thời gian kernel thực hiện chức năng được yêu cầu lại được tính vào thời gian process chạy.
Kernel process mặc dù có "stack pointer", tuy nhiên việc lưu trữ các register cùng với stack pointer không giống như việc lưu trữ đối với các process khác đơn giản vì kernel là 1 process đặc biệt có độ ưu tiên lớn hơn các process thông thường.
[Sửa] Clock task trong MINIX3
Clock task thực chất là I/O driver của đồng hồ nằm trong máy tính. Các device driver khác được đưa lên lớp trên trừ driver của clock là vì hầu như chỉ có kernel mới giao tiếp với clock, và clock chỉ giao tiếp với kernel nhằm đáp ứng cho việc định thì trong OS (timing signal).
[Sửa] System task trong MINIX3
System task đóng vai trò cung cấp các lời gọi chức năng của kernel cho các process ở lớp trên (server và driver). Ta có thể hình dung clock task như là 1 interface cung cấp các hàm cần thiết cho các lớp trên như: truy xuất I/O, sao chép các dữ liệu từ vùng nhớ này sang vùng nhớ khác,....
[Sửa] Kernel Call VS System Call
Kernel call là các lời gọi chức năng cấp thấp mà kernel cung cấp cho các server và driver ở lớp 2 và lớp 3 để thực hiện các chức năng cần thiết được yêu cầu (giao tiếp I/O). Trong khi đó system call lại là các lời gọi hàm cấp cao được yêu cầu bởi các user application ở lớp 4 như: fork, alarm, exec... Một system call có thể được thực hiện tương ứng bởi 1 kernel call, tuy nhiên cũng có nhiều system call phải được thực hiện bởi nhiều kernel call. System call trong MINIX3 được cung cấp theo chuẩn POSIX (chuẩn mà các system call các dòng UNIX tuân theo).
[Sửa] User-mode process
Các process nằm trong các lớp 2, 3, 4 đều có thể xem như nằm chung 1 lớp về lý thuyết được kernel đối xử như nhau. Mỗi process trong nhóm này đều được kernel điều khiển, định thời và đều được cung cấp 1 thời gian chạy nhấn định (quantum time). Các process này không được phép truy xuất trực tiếp I/O, không được phép truy xuất các vùng nhớ nằm ngoài vùng nhớ quy định mà kernel cung cấp cho mỗi process. Các process này được cung cấp các hàm chức năng nhất định dành cho user-mode.
Tuy nhiên các process nằm cũng được phân biệt với nhau bởi các lời gọi hàm cấp cao (kernel call) mà mỗi process được cung cấp. Process ở lớp 2 được cung cấp nhiều lời gọi hàm cấp cao nhất, tiếp đến là process ở lớp 3, process ở lớp 4 không được cung cấp các lờp gọi hàm đặc biệt nào thay vào đó chỉ được cung cấp các system call.
[Sửa] Driver và server process
Device Driver được tuy không được phép truy xuất trực tiếp I/O, nhưng có thể gửi kernel call yêu cầu các kernel được hoặc ghi dữ liệu ra các cổng I/O xác định. Việc hiện thực truy xuất I/O như thế này có thể chậm hơn nhưng nó tạo điều kiện để kernel kiểm tra xem driver có được phép truy xuất cổng I/O này không (hạn chế các trường hợp bug trong driver chẳng hạn driver của máy in lại truy xuất cổng audio...). Driver còn được phép yêu cầu kernel sao chép dữ liệu mới lấy được đến process khác.
Server process cũng giống như driver được cung cấp các lời gọi chức năng đặc biệt (kernel call) tuy nhiên server không được phép yêu cầu truy xuất I/O trực tiếp mà thay vào đó có thể gửi yêu cầu đến driver để yêu cần truy xuất I/O. Ngoài ra server còn cung cấp các system call cho lớp 4 user application sử dụng như: fork, exec, kill .... File system (FS)cung cấp các system call liên quan đến thao tác với các file trong OS, process manager (PM) cung cấp các system call liên quan đến tiến trình thực thi của process có thể thay đổi trạng thái của các process, thực hiện chức năng quản lý bộ nhớ.
Ngoài các process FS, PM trên lớp 3 còn có các process khác nhằm đáp ứng đầy đủ các chức năng của OS. Đáng chú ý là process reincarnation server (RS) chịu trách nhiệm xem xét các hoạt động của các driver process trong OS, có thể khởi động lại các driver process nếu nó không hoạt động đúng như mong muốn một cách trong suốt (không cần sự can thiệp của người dùng). Ngoài ra còng có information server (IS) cung cấp các thông tin trạng thái của các server và driver khác trong OS, các thông tin này rất có ích cho việc debug sữa chữa các bug trong code.
Một OS tốt cần phải đảm nhận được 2 nhiệm vụ: quản lý tài nguyên (manage resource) và cung cấp các chức năng system call (extended machine). Quản lý tài nguyên được thực hiện bởi các driver ở lớp 2 còn các system call được cung cấp ở lớp 3.
Một điểm đáng lưu ý trong hệ điều hành MINIX3 là chúng ta không cần phải compile lại toàn bộ hệ thống nếu muốn thêm bớt các server do cấu trúc thiết kế kiểu micro kernel mà MINIX3 được xây dựng. Các server và driver có thể được khởi động cùng lúc với OS hoặc có thể được khởi động sau. Cả server và driver được compile và lưu trữ như các chương trình bình thường khác tuy nhiên khi được khởi động các process này sẽ được nâng quyền bởi RS tức là có khả năng gọi các hàm kernel call được quy định cho process đó trong OS.
Driver và server gọi chung là các system process, chúng là các process đặc biệt cung cấp các chức năng cần thiết của OS. Mặc dù về lý thuyết các driver có quyền và độ ưu tiên cao hơn các server nhưng điều đó không hẳn là luôn luôn đúng nếu driver thuộc về các thiết bị chậm có thể sẽ không được ưu tiên bằng các server.
[Sửa] User application
Lớp 4 sẽ gồm các user process như shell, editor, compiler... và các chương trình khác. Process init trên lớp 4 sẽ được khởi động cùng lúc với Os và process này sẽ là cha của các user process còn lại. Có thể hình như ban đầu OS chỉ có process init, sau đó process init sẽ gọi hàm fork để tạo ra bản sao của chính nó và thực hiện hàm exec để chạy chương trình cần chạy (user login, shell...). Ngoài các process thông thường còn có các deamon (các process chạy ngầm) nhằm để phục vụ các các chức năng liên tục hoặc đợn các sự kiện cần thiết (chẳng hạn như sshd, nfsd...). Ta có thể cung cấp độ ưu tiên lớn hơn cho các process này.
[Sửa] Startup MINIX3
Trên thực tế với các dòng máy tính PC bộ xử lý x86, quá trình khởi động diễn ra cơ bản theo các bước: BIOS sẽ gọi chương trình chứa trên đĩa cứng (hard disk) để thực hiện việc boot. Tuy nhiên chương trình này có kích thước khá nhỏ 512 bytes thường được gọi là bootstrap, chương trình này thông thường sẽ được dùng để gọi chương trình khác lớn hơn để thực hiện việc khởi động mà ở hệ điều hành MINIX3 là boot.
Nếu đĩa cứng có nhiều partition thì sector đầu tiên của đĩa cúng sẽ chứa thông tin bảng các partition trong đĩa và partition chính dùng để khởi động. Sector đầu tiên của partition chính sẽ chứa bootstrap.
Sau khi chương trình boot trong MINIX3 được thực thi, chương trình này sẽ thực hiện việc sao chép boot image chứa kernel, server driver và user process init để thực hiện việc khởi động OS. Boot sẽ chuyển giao quyền điều khiển cho kernel và kernel sẽ giữ lại các thông tin cần thiết mà boot cung cấp (memmory map, video, bus ...). Các process trong boot image là những process độc lập. Sau khi kernel, process manager và file system được load và thực hiện những thủ tục cần thiết để có thể bắt đầu chạy bình thường các thành phần server, driver có thể được load một cách độc lập. Tuy nhiên RS phải được load sớm nhất có thể vì thành phần này cung cấp các chức năng cho phép 1 process bình thường có thể trở thành server, hoặc driver bằng cách cung cấp thêm các quyền gọi các hàm kernel call và cấp độ ưu tiên lớn hơn cho các process đó, ngoài ra RS được thi hành sớm cũng sẽ tạo điều kiện để tiến hành việc kiểm tra thường xuyên tình trạng hoạt động của các driver.
Việc khởi động MINIX3 đòi hỏi phải có ít nhất 1 disk driver, nếu OS sử dụng RAM disk thì phải có memmory driver. Disk này sẽ chứa root file system.
[Sửa] Thứ tự khởi động của OS
Kernel sẽ khởi động đầu tiên là clock task và system task, tiếp sau đó là process manager, file system. Sau đó process manager file system và kernel sẽ cùng nhau khởi động các server, driver và các process khác trong boot image. Khi các server và driver đã được load và thực hiện các thủ tục đầu tiên để có thể hoạt động bình thường, MINIX3 sẽ bắt đầu định thì cho các server và driver. Và chỉ khi nào các task, server và driver bị block thì process init mới được load và thực thi.
| Component | Description | Loaded by |
|---|---|---|
| Kernel | Kernel + clock and system task | boot image |
| PM | Process manager | boot image |
| FS | File system | boot image |
| RS | Reincarnation server | boot image |
| Memory | RAM disk driver | boot image |
| Log | Buffers log output | boot image |
| tty | Console and Keyboard driver | boot image |
| driver | Disk (at, bios, or floppy) driver | boot image |
| init | Parent of all user processes | boot image |
| floppy | Floppy driver (if booted from hard disk) | /etc/rc |
| IS | Information server (for debug dumps) | /etc/rc |
| CMOS | Reads CMOS clock to set time | /etc/rc |
| Random | Random number generator | /etc/rc |
| Printer | Printer driver | /etc/rc |
Các thành phần trên của MINIX3 không nhất thiết bắt buộc phải có để OS có thể hoạt động. Tuy nhiên MINIX3 được viết ban đầu cho máy PC x86 nên những thành phần trên là cần thiết. Ta có thể chỉ cần tạo một boot image chứa kernel và một inet server cùng driver của card mạng là có thể kết nối đến các máy tính khác yêu cầu các server cũng như các driver cần thiết được lưu trữ trên máy tính đó, down về máy và gắn vào kernel để chạy một hệ điều hành như bình thường(??!!).
[Sửa] System Initialization
init là user process đầu tiên được phép chạy, và là process cuối cùng được load bởi boot image. Trong MINIX3 không thực sự init là process cha của các process khác, khi mà trước init đã có các process khác được load và thực thi. Clock và system task là 2 process đặc biệt không được nhìn thấy từ "bên ngoài", 2 process này chỉ được nhìn thấy bởi kernel. Chúng không có Process ID và không được xem như là 1 phần của cây các process mà đỉnh nó là init. Process manager được nhận PID là 0 và nó không là cha cũng như là con của bất cứ process nào, nó là process đầu tiên được phép thực thi trong các lớp user-mode process. RS là cha của tất cả các process nào được load từ boot image tất nhiên là trừ PM.
RS có thể nói là cha của init tuy nhiên trên thực tế khi chạy MINIX3 ta thấy 1 điểm khá thú vị là RS là cha của init, như init cũng lại là cha của RS. Một chức năng khác của RS là khởi động các system process khác không nằm trong boot image mà được lưu trữ như những chương trình bình thường khác bằng cách nâng quyền các system process lúc ban đầu mới bắt đầu chạy, và cung cấp các lời gọi kernel calls được quy định cho các system process đó.
rc trong bảng trên là một script dùng để khởi động các system process. Đến lúc này thì root file system phải được nhận diện thì mới có thể thấy được file rc. Script rc cũng cung cấp việc kiểm tra xem OS có được shutdown đúng trong lần chạy trước đó hay không, nếu không đúng sẽ thực hiện việc kiểm tra các file nhằm đảm bảo cho OS chạy tốt.
Sau cùng là khởi động các daemon, cũng như khởi động terminal nhằm phục vụ cho việc login vào hệ thống.
[Sửa] Interprocess Communication
Các process trong MINIX3 là những process độc lập không chia sẽ chung các vùng nhớ nên việc giao tiếp giữa các process sẽ được thực hiện thông qua việc truyền nhận thông điệp (message passing). Có 3 hàm truyền thông điệp cơ bản:
send(dest, &message); receive(source, &message); sendrec(src_dst, &message);
Việc truyền nhận thông điệp được thực hiện thông qua việc sao chép các thông điệp từ process nguồn tới process đích bởi kernel. Không phải bất cứ process nào cũng có thể truyền nhận thông điệp với mọi process nó muốn. Việc truyền nhận thông điệp hầu như chỉ diễn ra ở task, driver và server còn các user process muốn truyền gửi thông điệp cho nhau chỉ có thể truyền nhận thông điệp theo hình chữ V tức là user process này phải gửi thông điệp cho server ở lớp thấp hơn và từ server này có thể gửi thông điệp lại cho user process khác.
Truyền nhận thông điệp trong MINIX3 được kiểm soát một cách kĩ lưỡng, mỗi process được quy định những process nào mà nó có thể truyền đến hoặc nhận từ process đó. Các user process bắt buộc phải sử dụng hàm sendrec khi muốn gửi thông điệp đến server vì ta không muốn user process cứ gửi thông điệp yêu cầu server thực hiện các tác vụ cho mình mà không đợi kết quả có nghĩa là khi user process thực hiện hàm sendrec, process sẽ bị block cho tới khi nào nhận được câu trả lời từ server. User process không được phép gửi thông điệp cho nhau vì khi đó server FS, PM không kiểm soát được nội dung và cách thức phục hồi nếu có sự cố xảy ra.
Truyền nhận thông điệp trong MINIX3 sử dụng theo cơ chế rendezvous tức là khi một process nếu thực hiện hàm send mà bên nhận không thực hiện hàm receive thì bên gửi sẽ bị block, tương tự nếu process thực hiện hàm receive nhưng bên gửi vẫn chưa gửi thông điệp thì bên cần nhận sẽ bị block. Việc hiện thực truyền nhận thông điệp theo cơ chế như vậy sẽ làm không cần phải tiến hành buffer các message cho process, và do đó không cần đến chuyện quản lý buffer cho các thông điệp.
Cần lưu ý thêm là kích thước các message trong MINIX3 đã được quy định sẵn nên sẽ không xảy ra tình trạng tràn thông điệp nếu thông điệp quá dài.
Để tránh tình trạng deadlock có thể xảy ra trong quá trình truyền thông điệp khi A send B thì B không được send A mà B chỉ có thể receive từ A.
Hạn chế của việc tryền gửi thông điệp là nơi gọi các hàm thường có nguy cơ bị block khi process đích chưa sẵn sàng cho việc truyền gửi thông điệp. Điều này sẽ là một hạn chế khi xử lý các interrupt, cũng như các exception. Để giải quyết tình trạng đó, MINIX3 đưa ra khái niệm notify - là các truyền thông điệp mà nơi gửi không bị block nếu nơi nhận chưa sẵn sàng (chưa thực hiện hàm receive).
Notify thường dùng để truyền các interrupt message cho các process, và thường sử dụng cho các system process giao tiếp với nhau. Mỗi system process sẽ có 1 bitmap chứa đựng các nơi đã gửi notify cho nó từ các system process khác, vì số lượng system process là có hạn nên notify có thể được hiện thực một cách dễ dàng. Khi một process gửi một notify cho một process thì bit ứng với process đó trong bitmap sẽ được bật lên 1. Nhưng làm sao 1 process không ở trong trạng thái receive lại có thể bật bit tương ứng với process đã gửi notify cho nó? Câu trả lời là không phải process nhận notify bật bit ứng với process gửi lên mà là kernel đã làm việc đó vì bitmap của system process nằm trong kernel data structure. Một notify không nhất thiết là từ một nguồn mà là có thể từ nhiều nguồn có thể sản sinh ra notify đó.
[Sửa] Process Scheduling
MINIX3 có kernel thuộc loại preemptive tức là process có độ ưu tiên cao sẽ được thực thi trước. Tuy nhiên MINIX3 còn cung cấp những chế độ linh hoạt hơn trong việc điều hành các process:
- Process sẽ bị block nếu thực hiện các yêu cầu I/O (hardware interrupt)
- User process sẽ bị block khi yêu cầu các system call. Lúc này server thực hiện system call đó sẽ được phép thực thi.
- Process bị block khi tryền nhận thông điệp mà đối tượng vẫn chưa sẵn sàng trong truyền nhận thông điệp ( software interrupt). Khi process bị block thì 1 process khác sẽ được lựa chọn để thực thi.
- Process đang thực thi nếu có interrupt xảy ra mà process đáp ứng interrupt đó có độ ưu tiên cao hơn thì process đáp ứng interrupt sẽ được thi thực trước. Sau khi thực thi xong sẽ trả quyền thực thi cho process ban đầu.
MINIX3 có 16 hàng đợi: IDLE process nằm ở hàng đợi thấp nhất kế đến là user process, server , driver, clock và system task là process có độ ưu tiên cao nhất.
Mỗi process sẽ được cung cấp thời gian chạy (quantum time). System process sẽ được cung cấp quantum time nhiều nhất để có thể thực thi đến khi bị block.
Process nếu sử dụng hết quantum time sẽ được đưa về cuối hàng đợi tuy nhiên nếu process đó cản trở sự thực thi của các process có độ ưu tiên thấp hơn thì sẽ bị hạ độ ưu tiên. Process cũng có thể được nâng độ ưu tiên nếu việc thực thi của nó không làm ảnh hưởng đến sự thực thi của các process có độ ưu tiên khác do process cần nhiều thời gian hơn để hoàn thành công việc.
Mỗi hàng đợi sẽ được định thì theo kiểu round robin trên hàng đợi đó.
Quantum time của process vẫn sẽ được tính nếu process gọi các hàm chức năng của hệ thống và bị block thì thời gian thực hiện các yêu cầu đó của system process vẫn sẽ được tính cho process.
Nếu 1 process bị block khi chờ I/O và nhường quyền thực thi cho process khác thì khi I/O được đáp ứng thì process sẽ được đưa lên đầu hàng đợi.
User process sẽ được thực thi khi các system process bị block. Điều này có nghĩa là khi tìm kiếm các process được phép thực thi MINIX3 sẽ ưu tiên các process đang ở trạng thái ready trên các hàng đợi có độ ưu tiên cao nhất.
