02 ਅਗ 2025·8 ਮਿੰਟ
ਐਂਡਰੂ ਐਸ. ਟੈਨਨਬਾਊਮ ਦਾ MINIX: ਕਰਨਲ ਡਿਜ਼ਾਇਨ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਸਿੱਖਾਉਣਾ
ਜਾਣੋ ਕਿ ਐਂਡਰੂ ਐਸ. ਟੈਨਨਬਾਊਮ ਨੇ MINIX ਨੂੰ OS ਦੇ ਅੰਦਰੂਨੀ ਤੱਤ ਸਿੱਖਾਉਣ ਲਈ ਕਿਵੇਂ ਬਣਾਇਆ, ਅਤੇ ਮਾਈਕਰੋਕਰਨਲ ਪਹੁੰਚ ਕਰਨਲ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਡਿਜ਼ਾਇਨ ਟਰੇਡਆਫ਼ ਬਾਰੇ ਕੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।
ਜਾਣੋ ਕਿ ਐਂਡਰੂ ਐਸ. ਟੈਨਨਬਾਊਮ ਨੇ MINIX ਨੂੰ OS ਦੇ ਅੰਦਰੂਨੀ ਤੱਤ ਸਿੱਖਾਉਣ ਲਈ ਕਿਵੇਂ ਬਣਾਇਆ, ਅਤੇ ਮਾਈਕਰੋਕਰਨਲ ਪਹੁੰਚ ਕਰਨਲ ਦੀ ਸੰਰਚਨਾ ਅਤੇ ਡਿਜ਼ਾਇਨ ਟਰੇਡਆਫ਼ ਬਾਰੇ ਕੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ।
MINIX ਇੱਕ ਛੋਟਾ, ਸਿੱਖਣ-ਕੇਂਦਰਤ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਹੈ ਜੋ ਐਂਡਰੂ ਐਸ. ਟੈਨਨਬਾਊਮ ਨੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਬਣਾਇਆ ਕਿ ਓਐਸ ਦੇ “ਅੰਦਰੁਨੀ ਹਿੱਸੇ” ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਹੋਵੇ। ਇਹ ਬੈਂਚਮਾਰਕ ਜਿੱਤਣ ਜਾਂ ਲੱਖਾਂ ਲੈਪਟਾਪਾਂ 'ਤੇ ship ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰ ਰਿਹਾ। ਇਸਦਾ ਉਦੇਸ਼ ਪੜ੍ਹਨ ਯੋਗ, ਟੈਸਟ ਕਰਨ ਯੋਗ ਅਤੇ ਵਿਆਖਿਆ ਕਰਨ ਯੋਗ ਹੋਣਾ ਹੈ—ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵੱਡੇ ਕੋਡਬੇਸ ਵਿੱਚ ਖੋ ਨਾ ਜਾਓ ਜਦੋਂ ਕਰਨਲ ਡਿਜ਼ਾਇਨ ਪੜ੍ਹਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਕਦੇ ਕਰਨਲ ਨਹੀਂ ਲਿਖਣੀ, ਫਿਰ ਵੀ ਕਰਨਲ estudo ਤੁਹਾਡੇ ਲਈ ਲਾਭਦਾਇਕ ਹੈ। ਕਰਨਲ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਪੇਰਫਾਰਮੈਂਸ (ਕੰਮ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਹੁੰਦਾ ਹੈ) ਅਤੇ ਰਿਲਾਇਬਿਲਟੀ (ਸਿਸਟਮ ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਬੱਗਾਂ ਅਤੇ ਫੇਲਿਯਰਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ) ਬਾਰੇ ਮੁੱਖ ਫੈਸਲਿਆਂ ਲਏ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਤੁਸੀਂ ਅਰਥ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਕਰਨਲ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕੀ ਹੈ—ਸੈਡੂਲਿੰਗ, ਮੈਮੋਰੀ, ਡਿਵਾਈਸ ਐਕਸੈਸ ਅਤੇ ਸੁਰੱਖਿਆ ਦੀਆਂ ਹੱਦਾਂ—ਤਾਂ ਤੁਸੀਂ ਹਰ ਰੋਜ਼ ਦੀ ਇঞ্জੀਨੀਅਰਿੰਗ ਦੇ ਪ੍ਰਸ਼ਨਾਂ ਬਾਰੇ ਸੋਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਕਰਨ ਲੱਗਦੇ ਹੋ:
ਇਹ ਲੇਖ MINIX ਨੂੰ ਕਰਨਲ ਆਰਕੀਟੈਕਚਰ ਦੀ ਇੱਕ ਸਾਫ਼, ਢਾਂਚਾਕਾਰ ਉਦਾਹਰਨ ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਤੁਸੀਂ ਮੁੱਖ ਧਾਰਣਾਵਾਂ ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਪਿੱਛੇ ਖੜੇ ਟਰੇਡਆਫ਼ਾਂ ਨੂੰ ਸਧਾ ਸਪਸ਼ਟ ਬੋਲਚਾਲ ਦੀ ਭਾਸ਼ਾ ਵਿੱਚ ਸਮਝੋਗੇ—ਜਿਆਦਾ ਜਾਰਗਨ ਤੋਂ ਬਿਨਾਂ।
ਤੁਹਾਨੂੰ ਗੰਭੀਰ ਗਣਿਤ ਦੀ ਲੋੜ ਨਹੀਂ ਪਏਗੀ, ਅਤੇ ਕਿਸੇ ਸਿਧਾਂਤਕ ਮਾਡਲ ਨੂੰ ਯਾਦ ਕਰਨ ਦੀ ਲੋੜ ਵੀ ਨਹੀਂ। ਇਸ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਕ ਪ੍ਰਯੋਗਕਾਰੀ ਮਾਨਸਿਕ ਮਾਡਲ ਵਿਕਸਿਤ ਕਰੋਗੇ ਕਿ ਇਕ OS ਕਿਸ ਤਰ੍ਹਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਉਹ ਹਿੱਸੇ ਕਿਵੇਂ ਗੱਲ-ਬਾਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਡਿਜ਼ਾਇਨ ਨਾਲ ਤੁਹਾਨੂੰ ਕੀ ਲਾਭ ਅਤੇ ਕੀ ਨੁਕਸਾਨ ਹੁੰਦੇ ਹਨ।
ਅਸੀਂ ਕਵਰ ਕਰਾਂਗੇ:
ਆਖਿਰ ਵਿੱਚ, ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਦੇਖਕੇ ਤੇਜ਼ੀ ਨਾਲ ਉਹਨਾਂ ਡਿਜ਼ਾਇਨ ਚੋਣਾਂ ਦੀ ਪਛਾਣ ਕਰ ਸਕੋਗੇ—ਅਤੇ ਉਹਨਾਂ ਦਾ ਕੀ ਅਰਥ ਹੈ।
ਐਂਡਰੂ ਐਸ. ਟੈਨਨਬਾਊਮ ਓਪਰੇਟਿੰਗ-ਸਿਸਟਮ ਸਿੱਖਿਆ ਵਿਚ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਆਵਾਜ਼ਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ—ਨਾ ਕਿ ਇਸ ਲਈ ਕਿ ਉਹ ਨੇ ਕੋਈ ਵਪਾਰਕ ਕਰਨਲ ਬਣਾਇਆ, ਪਰ ਇਸ ਲਈ ਕਿ ਉਹਨਾਂ ਨੇ ਲੋਕਾਂ ਨੂੰ ਕਰਨਲ ਕਿਵੇਂ ਸਿੱਖਦੇ ਹਨ ਉਸ 'ਤੇ ਧਿਆਨ ਦਿੱਤਾ। ਇੱਕ ਪ੍ਰੋਫੈਸਰ ਅਤੇ ਵੇਹੜੇ ਪ੍ਰਸਿੱਧ ਕਿਤਾਬਾਂ ਦੇ ਲੇਖਕ ਹੋਣ ਦੇ ਨਾਤੇ, ਉਹਨਾਂ ਨੇ ਇੱਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਨੂੰ ਇੱਕ ਸਿਖਾਉਣ ਵਾਲੇ ਉਪਕਰਣ ਵਜੋਂ ਲਿਆ: ਕੁਝ ਐਸਾ ਜੋ ਵਿਦਿਆਰਥੀ ਪੜ੍ਹ ਸਕਣ, ਤਰਕ ਕਰ ਸਕਣ, ਅਤੇ ਬਿਨਾਂ ਖੋਏ ਬਦਲ ਸਕਣ।
ਕਈ ਅਸਲੀ ਦੁਨੀਆਂ ਦੇ ਓਐਸ ਉਹ ਦਬਾਅ ਹੇਠ ਬਣਾਏ ਜਾਂਦੇ ਹਨ ਜੋ ਸ਼ੁਰੂਆਤੀਆਂ ਲਈ ਮਦਦਗਾਰ ਨਹੀਂ ਹੁੰਦੇ: ਪੇਰਫਾਰਮੈਂਸ ਟਿਊਨਿੰਗ, ਪਿਛੋਕੇ ਅਨੁਕੂਲਤਾ, ਬਹੁ-ਹਾਰਡਵੇਅਰ ਸਪੋਰਟ ਅਤੇ ਸਾਲਾਂ ਵਾਰੀ ਭਰਦੇ ਗਏ ਫੀਚਰ। ਟੈਨਨਬਾਊਮ ਦਾ MINIX ਨਾਲ ਲਕੜੀ ਵੱਖਰੀ ਸੀ। ਉਹ ਇੱਕ ਛੋਟਾ, ਸਮਝਣਯੋਗ ਸਿਸਟਮ ਚਾਹੁੰਦੇ ਸਨ ਜੋ ਮੂਲ OS ਧਾਰਣਾਵਾਂ—ਪ੍ਰੋਸੈਸ, ਮੈਮੋਰੀ ਪ੍ਰਬੰਧ, ਫਾਈਲ ਸਿਸਟਮ, ਅਤੇ ਇੰਟਰ-ਪ੍ਰੋਸੈਸ ਕਮਿਊਨਿਕੇਸ਼ਨ—ਨੂੰ ਦਰਸ਼ਾਇਆ ਜਾ ਸਕੇ ਬਿਨਾਂ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਮਿਲੀਅਨ ਲਾਈਨਾਂ ਕੋਡ ਦੇ ਰਾਹੀਂ ਖੰਗਾਲਣ ਦੇ।
ਇਹ “ਨਿਰੀਖਣਯੋਗ” ਸੋਚ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਧਾਰਣਾ ਨੂੰ ਡਾਇਗਰਾਮ ਤੋਂ ਅਸਲੀ ਸਰੋਤ ਤੱਕ ਟ੍ਰੇਸ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਕਰਨਲ ਨੂੰ ਜਾਦੂ ਵਾਂਗ ਨਹੀਂ ਦੇਖਦੇ—ਬਲਕਿ ਇੱਕ ਡਿਜ਼ਾਇਨ ਵਜੋਂ ਦੇਖਦੇ ਹੋ।
ਟੈਨਨਬਾਊਮ ਦੀਆਂ ਕਿਤਾਬੀ ਵਿਆਖਿਆਵਾਂ ਅਤੇ MINIX ਇੱਕ ਦੂਜੇ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੀਆਂ ਹਨ: ਕਿਤਾਬ ਮਾਨਸਿਕ ਮਾਡਲ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਅਸਲੀ ਸਬੂਤ। ਵਿਦਿਆਰਥੀ ਇੱਕ ਅਧਿਆਇ ਪੜ੍ਹਕੇ ਫਿਰ MINIX ਵਿੱਚੋਂ ਸੰਬੰਧਿਤ ਮਕੈਨਿਜ਼ਮ ਲੱਭ ਸਕਦੇ ਹਨ ਅਤੇ ਦੇਖ ਸਕਦੇ ਹਨ ਕਿ ਉਹ ਧਾਰਣਾ ਅਸਲ ਵਿਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ—ਡੇਟਾ ਸਟਰੱਕਚਰ, ਸੁਨੇਹਾ-ਫ਼ਲੋ, ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ ਸਮੇਤ।
ਇਹ ਜੋੜAssignment ਨੂੰ ਪ੍ਰਯੋਗਕਾਰੀ ਬਣਾਂਦਾ ਹੈ। ਸਿਧਾਂਤਕ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਥਾਂ, ਲਰਨਰ ਇੱਕ ਬਦਲਾਅ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹਨ, ਇੱਕ ਘੁੰਮਾਣ ਚਲਾਵਣਾ ਅਤੇ ਨਤੀਜੇ ਦੇਖ ਸਕਦੇ ਹਨ।
ਇੱਕ ਟੀਚਿੰਗ ਓਐਸ ਸਪਸ਼ਟਤਾ ਅਤੇ ਸਾਦਗੀ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ, ਸਰੋਤ ਉਪਲਬਧਤਾ ਅਤੇ ਸਥਿਰ ਇੰਟਰਫੇਸ ਜੋ ਪ੍ਰਯੋਗ ਨੂੰ ਭੜਕਾਉਂਦੇ ਹਨ। MINIX ਇਸ ਤਰ੍ਹਾਂ ਇਰਾਦੇ ਨਾਲ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਨਵਾਂ ਆਇਆ ਵਿਦਿਆਰਥੀ ਪੜ੍ਹ सके ਅਤੇ ਬਦਲ ਕਰ ਸਕੇ—ਫਿਰ ਵੀ ਇਹ ਕਾਫ਼ੀ ਹਕੀਕਤੀ ਹੈ ਤਾਂ ਜੋ ਉਹ ਉਹਨਾਂ ਟਰੇਡਆਫ਼ਾਂ ਨੂੰ ਵੀ ਸਿਖਾ ਸਕੇ ਜੋ ਹਰ ਕਰਨਲ ਨੂੰ ਕਰਨੀ ਪੈਂਦੀਆਂ ਹਨ।
1980 ਦੇ ਦਹਾਕੇ ਦੇ متوسط ਤੋਂ ਆਖਰੀ ਹਿੱਸੇ ਤੱਕ, UNIX ਵਿਚਾਰ ਯੂਨੀਵਰਸਿਟੀਆਂ ਵਿੱਚ ਫੈਲੇ ਹੋਏ ਸਨ: ਪ੍ਰੋਸੈਸ, ਫਾਈਲ-ਏਜ਼-ਸਟ੍ਰੀਮ, ਪਾਈਪ, ਪਰਮੀਸ਼ਨ ਅਤੇ ਇਹ ਧਾਰਣਾ ਕਿ ਇਕ ਓਐਸ ਨੂੰ ਇਕ ਗਠਿਤ ਸੰਕਲਪ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ—ਸਿਰਫ਼ ਇੱਕ ਵੇਂਡਰ ਦੇ ਬਲੈਕ ਬਾਕਸ ਵਜੋਂ ਨਹੀਂ।
ਪਕੜ ਇਹ ਸੀ ਕਿ ਅਮਲੀ ਪਾਸੇ ਤੇ UNIX ਸਿਸਟਮ ਜਿਹੜੇ ਕੈਂਪਸ 'ਤੇ ਸਨ ਉਹ ਜਿਆਦਾ ਮਹਿੰਗੇ, ਕਾਨੂੰਨੀ ਪਾਬੰਦੀਆਂ ਵਾਲੇ ਜਾਂ ਬਹੁਤ ਵੱਡੇ ਅਤੇ ਗੁੰਝਲਦਾਰ ਸਨ—ਜਿਨ੍ਹਾਂ ਨੂੰ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ “ਪੜ੍ਹਨ ਯੋਗ” ਤੌਰ ਤੇ ਦੇਣਾ ਮੁਸ਼ਕਲ ਸੀ। ਜੇ ਕੋਰਸ ਦਾ ਲਕੜੀ ਕਰਨਲ ਡਿਜ਼ਾਇਨ ਸਿੱਖਾਉਣਾ ਸੀ, ਤਾਂ ਇੱਕ ਐਸਾ ਢਾਂਚਾ ਚਾਹੀਦਾ ਸੀ ਜੋ ਵਿਦਿਆਰਥੀ ਇੱਕ ਸੈਮੈਸਟਰ ਵਿੱਚ ਕੰਪਾਇਲ, ਚਲਾਉ ਅਤੇ ਸਮਝ ਸਕਣ।
MINIX ਨੂੰ ਇੱਕ ਟੀਚਿੰਗ ਓਐਸ ਵਜੋਂ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜੋ UNIX ਵਰਗਾ ਅਨੁਭਵ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ, ਪਰ ਇਰਾਦੇ ਨਾਲ ਛੋਟਾ ਰਿਹਾ। ਇਹ ਮਿਲਾਪ ਮਹੱਤਵਪੂਰਨ ਸੀ: ਇਸ ਨੇ ਅਧਿਆਪਕਾਂ ਨੂੰ ਮਿਆਰੀ OS ਵਿਸ਼ਿਆਂ (ਸਿਸਟਮ ਕਾਲ, ਪ੍ਰੋਸੈਸ ਪ੍ਰਬੰਧ, ਫਾਈਲ ਸਿਸਟਮ, ਡਿਵਾਈਸ I/O) ਸਿਖਾਉਣ ਦੀ ਆਗਿਆ ਦਿੱਤੀ ਬਿਨਾਂ ਇਹ ਜ਼ਰੂਰੀ ਬਣਾਉਣ ਦੇ ਕਿ ਵਿਦਿਆਰਥੀ ਪਹਿਲਾਂ ਕਿਸੇ ਵੱਖਰੇ ਪਰਿਬੇਸ਼ ਨੂੰ ਸਿੱਖਣ।
ਉੱਪਰਲੇ ਪੱਧਰ 'ਤੇ, MINIX ਨੇ ਉਹੀ ਸਹਿਯੋਗਤਾ ਰੱਖੀ ਜੋ ਸਿੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਸੀ:
read() ਕਾਲ ਕਰਦਾ ਹੈ" ਤੋਂ "ਬਾਈਟ ਡਿਸਕ ਤੋਂ ਆਉਂਦੇ ਹਨ" ਤੱਕ ਟ੍ਰੇਸ ਕਰ ਸਕਣMINIX ਦੀਆਂ ਪਰਿਵੇਸ਼ਿਕ ਪਾਬੰਦੀਆਂ ਕਿਸੇ ਦੋਸ਼ ਨਹੀਂ ਸਨ—ਉਹ ਹੀ ਮਕਸਦ ਸਨ।
ਇਸ ਲਈ MINIX ਨੇ ਕੇਵਲ "ਇੱਕ ਹੋਰ UNIX ਬਣਾਉਣ" ਦਾ ਸਮੱਸਿਆ ਹੱਲ ਨਹੀਂ ਕੀਤਾ। ਇਹ ਇਹ ਕਿੱਤਾ: ਸਿੱਖਣ ਲਈ ਉਦਾ਼ਰਤ ਕੀਤਾ ਗਿਆ ਇੱਕ UNIX-ਨੁਮਾ ਸਿਸਟਮ ਬਣਾਉ—ਸੰਕੁਚਿਤ, ਸਮਝਣਯੋਗ ਅਤੇ ਅਸਲ ਦੁਨੀਆਂ ਦੇ ਇੰਟਰਫੇਸਾਂ ਦੇ ਨੇੜੇ ਤਾਂ ਜੋ ਸਬਕ ਟ੍ਰਾਂਸਫਰ ਹੋ ਸਕਣ।
ਇੱਕ ਮਾਈਕਰੋਕਰਨਲ ਉਹ ਕਰਨਲ ਹੈ ਜੋ जानਬूਝ ਕੇ ਛੋਟਾ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਵੱਡੇ ਪ੍ਰਿਵਿਲੇਜਡ ਕੋਡ ਬਲੌਬ ਵਿੱਚ ਹਰ OS ਫੀਚਰ ਰੱਖਣ ਦੀ ਥਾਂ, ਇਹ ਸਿਰਫ਼ ਅਹਿਮ ਚੀਜ਼ਾਂ ਨੂੰ "ਕਰਨਲ ਮੋਡ" ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਕਾਮ ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਸਧੀ ਬੋਲੀ ਵਿੱਚ: ਮਾਈਕਰੋਕਰਨਲ ਇੱਕ ਪਤਲਾ ਰੈਫਰੀ ਹੈ ਜੋ ਨਿਯਮ ਲਾਉਂਦਾ ਅਤੇ ਖਿਡਾਰੀਆਂ ਵਿਚਕਾਰ ਨੋਟ ਪਾਸ ਕਰਵਾਉਂਦਾ ਹੈ—ਪੂਰੀ ਟੀਮ ਨਹੀਂ ਬਣਦਾ।
MINIX ਦਾ ਮਾਈਕਰੋਕਰਨਲ ਉਹਨਾਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਰੱਖਦਾ ਹੈ ਜੋ ਸਚਮੁੱਚ ਹਾਰਡਵੇਅਰ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਰੱਖਦੀਆਂ ਹਨ:
ਇਹ ਛੋਟਾ ਕੋਰ ਪੜ੍ਹਣ, ਟੈਸਟ ਕਰਨ ਅਤੇ ਤਰਕ ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦਾ ਹੈ—ਬਿਲਕੁਲ ਉਹੀ ਜੋ ਤੁਸੀਂ ਇੱਕ ਟੀਚਿੰਗ ਓਐਸ 'ਚ ਚਾਹੁੰਦੇ ਹੋ।
ਕਈ ਹਿੱਸੇ ਜੋ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ “ਓਐਸ” ਕਹਿੰਦੇ ਹਨ MINIX ਵਿੱਚ ਵੱਖਰੇ ਯੂਜ਼ਰ-ਸਪੇਸ ਸਰਵਰਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ:
ਇਹ ਹੋਰਾਂ ਵਾਂਗ ਹੀ ਓਐਸ ਦਾ ਹਿੱਸਾ ਹਨ, ਪਰ ਇਹ ਆਮ ਪ੍ਰੋਗਰਾਮਾਂ ਵਾਂਗ ਵਰਤਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਕੋਲ ਸੀਮਿਤ ਅਧਿਕਾਰ ਹੁੰਦੇ ਹਨ। ਜੇ ਕੋਈ ਇੱਕ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹ ਸਾਰੀ ਮਸ਼ੀਨ ਨੂੰ ਡਾਉਨ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਮੋਨੋਲਿਥਿਕ ਕਰਨਲ ਵਿੱਚ, ਫਾਈਲ ਸਿਸਟਮ ਇੱਕ ਡਰਾਈਵਰ ਨੂੰ ਅੰਦਰੂਨੀ ਫੰਕਸ਼ਨ ਕਾਲ ਰਾਹੀਂ ਸਧੇ ਤੌਰ 'ਤੇ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ। MINIX ਵਿੱਚ, ਫਾਈਲ ਸਿਸਟਮ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਡ੍ਰਾਈਵਰ ਸਰਵਰ ਨੂੰ ਮੇਸੇਜ ਭੇਜਦਾ ਹੈ।
ਇਸ ਨਾਲ ਤਰਕ ਕਰਨ ਦਾ ਢੰਗ ਬਦਲ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਇੰਟਰਫੇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ—"ਕਿਹੜੇ ਸੁਨੇਹੇ ਹਨ, ਉਨ੍ਹਾਂ ਵਿੱਚ ਕੀ ਡੇਟਾ ਹੁੰਦਾ ਹੈ, ਕੀ ਜਵਾਬ ਦਾ ਮਤਲਬ ਹੈ"—ਬਜਾਏ ਕਿ ਪੂਰੇ ਕਰਨਲ ਵਿਚ ਅੰਦਰੂਨੀ ਡੇਟਾ ਸਟਰੱਕਚਰ ਸਾਂਝੇ ਕਰਨ ਦੇ।
ਮਾਈਕਰੋਕਰਨਲ ਪਹੁੰਚ ਫੌਲਟ ਆਇਸੋਲੇਸ਼ਨ ਅਤੇ ਸਾਫ਼ ਬਾਊਂਡਰੀਜ਼ ਦਿੰਦੀ ਹੈ, ਪਰ ਇਸ ਦੇ ਕੁਝ ਖਰਚ ਵੀ ਹਨ:
MINIX ਦੀ ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਇਹ ਟਰੇਡਆਫ਼ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ—ਨਾ ਕਿ ਸਿਰਫ ਸਿਧਾਂਤ ਵਿਚ—ਛੋਟਾ ਕੋਰ, ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ, ਅਤੇ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਜੋ ਨਤੀਜਿਆਂ ਨੂੰ ਦਰਸ਼ਾਉਂਦਾ ਹੈ।
MINIX ਨੂੰ ਸਮਝਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ "ਕਿਸਨੂੰ ਭਰੋਸਾ ਕੀਤਾ ਜਾਣا ਚਾਹੀਦਾ ਹੈ" ਅਤੇ "ਕਿਸ ਨੂੰ ਸਧਾਰਨ ਪ੍ਰੋਗਰਾਮ ਵਾਂਗਿਆ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ" ਦੇ ਵਿਚਕਾਰ ਸਾਫ਼ ਹੱਦਾਂ ਖਿੱਚਦਾ ਹੈ। ਬੜੇ ਕਰਣਲ ਵਿੱਚ ਜਿਆਦਾ ਕੋਡ ਇੱਕ ਹੀ ਥਾਂ ਰੱਖਣ ਦੀ ਥਾਂ, MINIX ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਕਈ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦਾ ਹੈ ਜੋ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਗੱਲਬਾਤ ਕਰਦੇ ਹਨ।
ਉੱਚ-ਸਤਰ 'ਤੇ, MINIX ਇਸ ਤਰ੍ਹਾਂ ਸੰਗਠਿਤ ਹੈ:
ਇਹ ਵੰਡ concerns ਨੂੰ ਵੱਖ-ਵੱਖ ਬਾਕਸਾਂ ਵਿੱਚ ਫੈਲਾਉਂਦੀ ਹੈ: ਹਰ ਹਿੱਸਾ ਇੱਕ ਨੀਚਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਵਿਦਿਆਰਥੀ ਇੱਕ ਹਿੱਸੇ ਦਾ ਅਧਿਐਨ ਕਰ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਪੂਰੇ ਓਐਸ ਨੂੰ ਮਨ ਵਿਚ ਰੱਖਣ ਦੀ ਲੋੜ ਪਏ।
ਜਦੋਂ ਇੱਕ ਯੂਜ਼ਰ ਪ੍ਰੋਗਰਾਮ ਕਿਸੇ ਫਾਈਲ ਤੋਂ ਪੜ੍ਹਨ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਅਰਜ਼ੀ ਆਮ ਤੌਰ 'ਤੇ ਯਹੀਂ ਰਾਹ ਲੰਦੀ ਹੈ:
MINIX ਇੱਕ ਉਪਯੋਗੀ ਅੰਤਰ ਦਿਖਾਉਂਦਾ ਹੈ: kernel ਜ਼ਿਆਦਾ ਤਰ ਮਕੈਨਿਜ਼ਮ (ਟੂਲ: scheduling primitives, message passing) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਪਾਲਸੀ (ਕੌਣ ਨੂੰ ਕੀ ਮਿਲਦਾ, ਫਾਈਲਾਂ ਕਿਵੇਂ ਆਯੋਜਿਤ ਹੁੰਦੀਆਂ) ਸਰਵਰਾਂ ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ। ਇਹ ਵੰਡ ਸਿੱਖਣ ਵਾਲਿਆਂ ਨੂੰ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਪਾਲਸੀ ਬਦਲਣ ਲਈ ਸਾਰਥਕ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ ਕੋਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।
ਮਾਈਕਰੋਕਰਨਲ ਜਿਆਦਾ “ਓਐਸ ਕੰਮ” ਨੂੰ ਵੱਖਰੇ ਪ੍ਰੋਸੈਸਾਂ (ਜਿਵੇਂ ਫਾਈਲ ਸਿਸਟਮ, ਡਿਵਾਈਸ ਡ੍ਰਾਈਵਰ, ਅਤੇ ਸਰਵਰ) ਵਿੱਚ ਧੱਕ ਦਿੰਦਾ ਹੈ। ਇਹ ਕੰਮ ਤਬ ਹੀ ਚੱਲਦਾ ਹੈ ਜਦ ਇਹ ਹਿੱਸੇ ਇਕ ਦੂਜੇ ਨਾਲ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਕਰ ਸਕਣ। MINIX ਵਿੱਚ ਇਸ ਗੱਲਬਾਤ ਨੂੰ ਮੇਸੇਜ ਪਾਸਿੰਗ ਕਹਿੰਦੇ ਹਨ, ਅਤੇ ਇਹ ਕੇਂਦਰੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਰਨਲ ਡਿਜ਼ਾਇਨ ਨੂੰ ਲੁਕਿਆ ਹੋਇਆ ਸਾਂਝੇ ਰਾਜ ਦੇ ਬਦਲੇ ਇੰਟਰਫੇਸ ਬਣਾਉਣ ਦਾ ਅਭਿਆਸ ਬਣਾਉਂਦਾ ਹੈ।
ਉੱਚ-ਸਤਰ 'ਤੇ, ਮੇਸੇਜ ਪਾਸਿੰਗ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕ ਕੰਪੋਨੇਟ ਦੂਜੇ ਨੂੰ ਇੱਕ ਸੰਰਚਿਤ ਬੇਨਤੀ ਭੇਜਦਾ—"ਇਹ ਫਾਈਲ ਖੋਲ੍ਹੋ", "ਇਹ ਬਾਈਟ ਪੜ੍ਹੋ", "ਮੈਨੂੰ ਹੁਣ ਦਾ ਸਮਾਂ ਦਿਓ"—ਅਤੇ ਇੱਕ ਸੰਰਚਿਤ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਦਾ। ਅੰਦਰੂਨੀ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰਨ ਜਾਂ ਸਾਂਝੇ ਮੈਮੋਰੀ 'ਚ ਚੁੱਕਣ ਦੀ ਥਾਂ, ਹਰ ਸਭਿਅੰਸ਼ ਨੇ ਪਰਿਭਾਸ਼ਿਤ ਚੈਨਲ ਰਾਹੀਂ ਜਾਣਾ ਹੋਂਦਾ ਹੈ। ਇਹ ਵੰਡ ਸਿੱਖਣ ਲਈ ਖ਼ਾਸ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਸੀਮਾ ਵੱਲ ਇੰਗਲਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕਹਿ ਸਕਦੇ ਹੋ, “ਇਸ ਹੱਦ ਦੇ ਪਿੱਛੇ ਸਭ ਕੁਝ ਇੱਕ ਸੁਨੇਹਾ ਹੈ।”
ਸਿੰਕ੍ਰੋਨਸ ਮੇਸੇਜਿੰਗ ਫੋਨ ਕਾਲ ਵਾਂਗ ਹੈ: ਭੇਜਣ ਵਾਲਾ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਪ੍ਰਾਪਤਕਰਤਾ ਬੇਨਤੀ ਸੰਭਾਲ ਕੇ ਜਵਾਬ ਨਾ ਦੇਵੇ। ਇਹ ਰੇਖੀਅਨ ਫਲੋ ਹੈ, ਇਸ ਲਈ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਸੌਖਾ ਹੁੰਦਾ है।
ਅਸਿੰਕ੍ਰੋਨਸ ਮੇਸੇਜਿੰਗ ਈਮੇਲ ਵਰਗੀ ਹੈ: ਤੁਸੀਂ ਬੇਨਤੀ ਭੇਜ ਦਿੰਦੇ ਹੋ ਅਤੇ ਅੱਗੇ ਕੰਮ ਜਾਰੀ ਰੱਖਦੇ ਹੋ, ਜਵਾਬ ਬਾਅਦ ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਰਿਸਪਾਂਸਨਸ ਅਤੇ concurrency ਵਧਾ ਸਕਦਾ ਹੈ, ਪਰ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ pendings, ਆਰਡਰਿੰਗ ਅਤੇ ਟਾਈਮਆਉਟਸ ਨੂੰ ਟਰੇਕ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
IPC ਨਾਲ ਓਵਰਹੈੱਡ ਆਉਂਦਾ ਹੈ: ਡੇਟਾ ਪੈਕੇਜ ਕਰਨਾ, ਕੋਂਟੈਕਸਟ-ਸਵਿੱਚ, ਅਧਿਕਾਰ ਵੈਰਿਫਿਕੇਸ਼ਨ, ਅਤੇ ਬਫਰਾਂ ਦੀ ਕਾਪੀ/ਮੈਪਿੰਗ। MINIX ਇਹ ਲਾਗਤ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਵਿਦਿਆਰਥੀ ਸਮਝਦੇ ਹਨ ਕਿ ਕੁਝ ਸਿਸਟਮ ਮੋਨੋਲਿਥਿਕ ਡਿਜ਼ਾਇਨਾਂ ਨੂੰ ਕਿਉਂ ਤਰਜੀਹ ਦਿੰਦੇ ਹਨ।
ਦੂਜੇ ਪਾਸੇ, ਡੀਬੱਗਿੰਗ ਆਮ ਤੌਰ 'ਤੇ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ। ਜਦ ਨਾਕਾਮੀ ਸਪਸ਼ਟ ਸੁਨੇਹਾ ਹੱਦਾਂ 'ਤੇ ਹੁੰਦੀ ਹੈ, ਤੁਸੀਂ ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਲੌਗ ਕਰਕੇ ਢੰਗ ਨਾਲ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹੋ ਅਤੇ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਸਰਵਰ ਗਲਤ ਕਰ ਰਿਹਾ ਹੈ—ਬਿਨਾਂ ਇਹ ਧਾਰਨਾ ਕੀਤੇ ਕਿ "ਕਰਨਲ ਇੱਕ ਵੱਡਾ ਬਲੌਬ ਹੈ।"
ਸਪਸ਼ਟ IPC ਇੰਟਰਫੇਸ ਤੁਹਾਨੂੰ ਅਨੁਸ਼ਾਸਨਵੰਦ ਸੋਚ ਕਰਨ ਲਈ ਮਜ਼ਬੂਰ ਕਰਦੇ ਹਨ: ਕਿਹੜੇ ਇਨਪੁੱਟ ਮਨਜ਼ੂਰ ਹਨ, ਕਿਹੜੀਆਂ ਗਲਤੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਕਿਹੜਾ ਸਟੇਟ ਨਿਜੀ ਹੈ। ਵਿਦਿਆਰਥੀ ਕਰਨਲ ਡਿਜ਼ਾਇਨ ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਸਿੱਖਦੇ ਹਨ ਜਿਵੇਂ ਨੈੱਟਵਰਕ ਬਣਾਉਂਦੇ ਹਨ: ਪਹਿਲਾਂ ਕਰਾਰ (contracts), ਫਿਰ ਅਮਲ।
MINIX ਅਸਲੀ ਬਣਦਾ ਹੈ ਜਦੋਂ ਇਹ ਡਾਇਗ੍ਰਾਮ ਹੋਣਾ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਚਲਾਉਣਯੋਗ ਕੰਮ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ: ਪ੍ਰੋਸੈਸ ਜੋਬਲਾਕ ਹੋ ਜਾਂਦੇ ਹਨ, ਸੈਡੂਲਰ ਲੋਡ ਹੇਠ ਬਦਲਦਾ ਹੈ, ਅਤੇ ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਜਿਹੜੀਆਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਮਹਿਸੂਸ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਉਹ ਹਿੱਸੇ ਹਨ ਜੋ ਇੱਕ ਓਐਸ ਨੂੰ ਭਾਉਤਿਕ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ।
ਇੱਕ ਪ੍ਰੋਸੈਸ ਇੱਕ ਚੱਲ ਰਹੇ ਪ੍ਰੋਗਰਾਮ ਦਾ ਕੰਟੇਨਰ ਹੁੰਦਾ ਹੈ: ਇਸਦਾ CPU ਸਟੇਟ, ਐਡਰੈੱਸ ਸਪੇਸ, ਅਤੇ ਇਸਦੇ ਸਰੋਤ। MINIX ਵਿੱਚ ਤੁਸੀਂ ਜਲਦੀ ਸਿੱਖਦੇ ਹੋ ਕਿ “ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਚੱਲ ਰਿਹਾ ਹੈ” ਇਕ ਇਕੱਲੀ ਚੀਜ਼ ਨਹੀਂ—ਇਹ ਇੱਕ ਰਾਜ ਦਾ ਬੰਡਲ ਹੈ ਜਿਸਨੂੰ kernel ਸ਼ੁਰੂ, ਰੋਕ, ਮੁੜ ਚਾਲੂ ਅਤੇ ਰੋਕ ਸਕਦਾ ਹੈ।
ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਲਗਭਗ ਹਰ OS ਨੀਤੀ (ਕੌਣ ਅਗਲਾ ਚੱਲੇਗਾ, ਕੌਣ ਕੀ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ, ਅਸਫਲਤਾ ਤੇ ਕਿਹੜੀ ਕਾਰਵਾਈ) ਪ੍ਰੋਸੈਸਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਹੀ ਵਿਅਕਤ ਹੁੰਦੀ ਹੈ।
ਸੈਡੂਲਿੰਗ CPU ਸਮੇਂ ਲਈ ਨਿਯਮਾਂ ਦੀ ਕਿਤਾਬ ਹੈ। MINIX ਸੈਡੂਲਿੰਗ ਨੂੰ ਵੱਖਰਾ ਮਹਿਸੂਸ ਕਰਵਾਂਦਾ ਹੈ: ਜਦ ਵਧੇਰੇ ਪ੍ਰੋਸੈਸ ਚਾਹੁੰਦੇ ਹਨ ਚੱਲਣਾ, OS ਨੂੰ ਇੱਕ ਕ੍ਰਮ ਅਤੇ ਸਮਾਂ ਸਲਾਈਸ ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ। ਛੋਟੀਆਂ ਚੋਣਾਂ ਵੀ ਦਰਸ਼ਨੀ ਨਤੀਜੇ ਦਿਖਾਂਦੀਆਂ ਹਨ:
ਮਾਈਕਰੋਕਰਨਲ-ਸਟਾਈਲ ਸਿਸਟਮ ਵਿੱਚ, ਸੈਡੂਲਿੰਗ ਸੰਚਾਰ ਨਾਲ ਵੀ ਗੁੰਝੀ ਹੋ ਜਾਂਦੀ ਹੈ: ਜੇ ਕੋਈ ਸਰਵਿਸ ਪ੍ਰੋਸੈਸ ਦੇਰੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਦੇ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰਨ ਵਾਲੀ ਸਾਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਧੀਮੀ ਮਹਿਸੂਸ ਹੋਏਗੀ।
ਮੈਮੋਰੀ ਪ੍ਰਬੰਧ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਾਂ ਨੂੰ RAM ਕਿਵੇਂ ਮਿਲਦੀ ਹੈ ਅਤੇ ਉਹ ਕੀ ਛੂਹ ਸਕਦੇ ਹਨ। ਇਹ ਉਹ ਹੱਦ ਹੈ ਜੋ ਇੱਕ ਪ੍ਰੋਸੈਸ ਨੂੰ ਦੂਜੇ ਉੱਤੇ ਲਿਖਣ ਤੋਂ ਰੋਕਦੀ ਹੈ।
MINIX ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ, ਮੈਮੋਰੀ-ਸਬੰਧੀ ਕੰਮ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ: kernel ਨੀਚੇ-ਲੇਵਲ ਸੁਰੱਖਿਆ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਉੱਚ-ਸਤਹ ਨੀਤੀਆਂ ਸਰਵਿਸਾਂ ਵਿੱਚ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਵੰਡ ਇੱਕ ਮੁੱਖ ਸਿੱਖਿਆ ਦਿਖਾਉਂਦੀ ਹੈ: ਪ੍ਰਬੰਧਨ ਨੂੰ ਫੈਸਲਿਆਂ ਤੋਂ ਵੱਖ ਕਰਨਾ ਸਿਸਟਮ ਨੂੰ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਆਸਾਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਕੋਈ ਯੂਜ਼ਰ-ਸਪੇਸ ਸਰਵਿਸ ਕਰੈਸ਼ ਕਰਦੀ ਹੈ, ਤਾਂ MINIX ਅਕਸਰ kernel ਅਤੇ ਬਾਕੀ ਸਿਸਟਮ ਨੂੰ ਚਲਾਉਣ ਰੱਖ ਸਕਦਾ ਹੈ—ਫੇਲਿਯਰ ਸੀਮਿਤ ਰਹਿੰਦਾ ਹੈ। ਇੱਕ ਮੋਨੋਲਿਥਿਕ ਡਿਜ਼ਾਇਨ ਵਿੱਚ, ਉਹੀ ਬੱਗ privileges ਵਾਲੇ ਕੋਡ ਵਿੱਚ ਹੋਣ ਕਾਰਨ ਸਾਰੇ kernel ਨੂੰ ਡਾਊਨ ਕਰ ਸਕਦੀ ਹੈ।
ਇਹ ਇੱਕ ਹੀ ਫਰਕ ਡਿਜ਼ਾਇਨ ਫੈਸਲਿਆਂ ਨੂੰ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਦਾ ਹੈ: ਆਇਸੋਲੇਸ਼ਨ ਸੁਰੱਖਿਆ ਸੁਧਾਰਦਾ ਹੈ, ਪਰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਵਿੱਚ ਓਵਰਹੈੱਡ ਅਤੇ ਜਟਿਲਤਾ ਵਧ ਹੁੰਦੀ ਹੈ। MINIX ਤੁਹਾਨੂੰ ਇਹ ਟਰੇਡਆਫ਼ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਕੇਵਲ ਪੜ੍ਹਾਉਂਦਾ।
ਕਰਨਲ ਬਹਿਸਾਂ ਅਕਸਰ ਇੱਕ ਮੈਦਾਨੀ ਲੜਾਈ ਵਾਂਗ ਸੁਣਾਈਂ ਦਿੰਦੀਆਂ ਹਨ: ਮਾਈਕਰੋਕਰਨਲ ਦੇਖੋ ਜਾਂ ਮੋਨੋਲਿਥਿਕ ਚੁਣੋ। MINIX ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਵੇਲੇ ਕੰਮ ਆਉਂਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸੋਚਣ ਵਾਲਾ ਸਾਧਨ ਮੰਨੋ। ਇਹ ਦਰਸਾਂਦਾ ਹੈ ਕਿ ਕਰਨਲ ਆਰਕੀਟੈਕਚਰ ਚੋਣਾਂ ਦੀ ਇੱਕ ਸਪਰਕਟਮ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਇਕਲਾ "ਸਹੀ" ਜਵਾਬ।
ਇੱਕ ਮੋਨੋਲਿਥਿਕ kernel ਬਹੁਤ ਸਾਰੀਆਂ ਸਰਵਿਸਾਂ ਨੂੰ ਇੱਕ ਪ੍ਰਿਵਿਲੇਜਡ ਸਪੇਸ ਵਿੱਚ ਰੱਖਦਾ—ਡਿਵਾਈਸ ਡ੍ਰਾਈਵਰ, ਫਾਈਲ ਸਿਸਟਮ, ਨੈੱਟਵਰਕ, ਆਦਿ। ਇੱਕ ਮਾਈਕਰੋਕਰਨਲ ਪ੍ਰਿਵਿਲੇਜਡ "ਕੋਰ" ਨੂੰ ਛੋਟਾ ਰੱਖਦਾ (ਸੈਡੂਲਿੰਗ, ਬੁਨਿਆਦੀ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧ, IPC) ਅਤੇ ਬਾਕੀ ਨੂੰ ਵੱਖਰੇ ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਸੈਸ ਵਜੋਂ ਚਲਾਉਂਦਾ।
ਇਹ ਸ਼ਿਫਟ ਟਰੇਡਆਫ਼ਾਂ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ:
ਜਨਰਲ-ਪਰਪਜ਼ ਸਿਸਟਮ ਪੇਰਫਾਰਮੈਂਸ ਅਤੇ ਅਨੁਕੂਲਤਾ ਲਈ ਵੱਡਾ kernel ਕਬੂਲ ਕਰ ਸਕਦੇ ਹਨ (ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ, ਵੱਖ-ਵੱਖ ਵਕਤੀਆਂ ਦਾ ਲੋਡ)। ਜਿੱਥੇ ਭਰੋਸੇਯੋਗਤਾ, ਰਖ-ਰਖਾਅ, ਜਾਂ ਮਜ਼ਬੂਤ ਵੰਡ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ (ਕੁਝ ਐਂਬੈਡਡ ਅਤੇ ਸੁਰੱਖਿਆ-ਕੇਂਦਰਤ ਡਿਜ਼ਾਇਨ) ਉੱਥੇ ਮਾਈਕਰੋਕਰਨਲ-ਸਮਾਨ ਰਚਨਾ ਚੁਣੀ ਜਾ ਸਕਦੀ ਹੈ। MINIX ਤੁਹਾਨੂੰ ਇਹ ਸਿਖਾਉਂਦਾ ਹੈ ਕਿ ਚੋਣਾਂ ਨੂੰ ਲਕੜੀ ਦੇ ਆਧਾਰ 'ਤੇ ਬੁਝਾਇਆ ਜਾਵੇ—ਵਿਚਾਰਧਾਰਾ ਤੋਂ ਨਹੀਂ।
ਡਿਵਾਈਸ ਡ੍ਰਾਈਵਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ ਜੋ crashing ਜਾਂ ਅਣਚਾਹੀ ਵਰਤਾਰਾ ਪੈਦਾ ਕਰਦੇ ਹਨ। ਉਹ ਇਕ ਅਜਿਹਾ ਹੱਦ 'ਤੇ ਬੈਠਦੇ ਹਨ: ਉਹਨਾਂ ਨੂੰ ਹਾਰਡਵੇਅਰ ਤੱਕ ਡੂੰਘੀ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹ interrupt ਅਤੇ timing quirks ਦਾ ਜਵਾਬ ਦੇਦੇ ਹਨ, ਅਤੇ ਅਕਸਰ ਬਹੁਤ ਸਾਰੇ ਵੇਂਡਰ-ਨਿਰਪੇਕ ਕੋਡ ਰੱਖਦੇ ਹਨ। ਇੱਕ ਪਰੰਪਰਾਗਤ ਮੋਨੋਲਿਥਿਕ kernel ਵਿੱਚ, ਇੱਕ buggy driver kernel ਮੈਮੋਰੀ ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਲਾਕ ਫੈਸਲਾ ਹੋਣ 'ਤੇ ਫਸ ਸਕਦਾ ਹੈ—ਜੋ ਪੂਰੇ ਸਿਸਟਮ ਨੂੰ ਡਾਉਨ ਕਰ ਦੇਂਦਾ ਹੈ।
MINIX ਇੱਕ ਮਾਈਕਰੋਕਰਨਲ ਪਹੁੰਚ ਵਰਤਦਾ ਹੈ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੇ ਡ੍ਰਾਈਵਰ ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਸੈਸਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ ਨਾ ਕਿ ਪ੍ਰਿਵਿਲੇਜਡ kernel ਕੋਡ ਵਜੋਂ। ਮਾਈਕਰੋਕਰਨਲ ਸਿਰਫ਼ ਅਹਮ ਚੀਜ਼ਾਂ (ਸੈਡੂਲਿੰਗ, ਨੀਵਾਂ ਮੈਮੋਰੀ ਪ੍ਰਬੰਧ, ਅਤੇ IPC) ਰੱਖਦਾ ਹੈ ਅਤੇ ਡ੍ਰਾਈਵਰ ਉਸਨੂੰ ਸਪਸ਼ਟ ਸੁਨੇਹਿਆਂ ਰਾਹੀਂ خطاب ਕਰਦੇ ਹਨ।
ਸਿੱਖਣ ਦਾ ਫਾਇਦਾ ਤੁਰੰਤ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ "ਭਰੋਸੇਯੋਗ ਕੋਰ" ਦਿਖਾ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਦਿਖਾ ਸਕਦੇ ਹੋ ਕਿ ਬਾਕੀ ਸਭ—ਡ੍ਰਾਈਵਰ ਸਮੇਤ—ਇੰਟਰਫੇਸਾਂ ਰਾਹੀਂ ਕਿਵੇਂ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਛੁਪੇ ਹੋਏ ਸਾਂਝੇ ਮੈਮੋਰੀ ਤਰਿਕਿਆਂ ਰਾਹੀਂ।
ਜਦੋਂ ਇੱਕ ਡ੍ਰਾਈਵਰ ਅਲੱਗ ਹੁੰਦਾ ਹੈ:
ਇਹ "ਕਰਨਲ ਜਾਦੂ" ਨੂੰ "ਕਰਨਲ ਇੱਕ ਸੈੱਟ ਕੰਟਰੈਕਟਾਂ ਦਾ ਹੈ" ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਆਇਸੋਲੇਸ਼ਨ ਮੁਫਤ ਨਹੀਂ ਹੈ। ਸਥਿਰ ਡ੍ਰਾਈਵਰ ਇੰਟਰਫੇਸ ਡਿਜ਼ਾਈਨ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਮੇਸੇਜ ਪਾਸਿੰਗ ਸਿੱਧੇ ਫੰਕਸ਼ਨ ਕਾਲਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਡੀਬੱਗਿੰਗ ਵੰਡਿਆ ਹੋ ਸਕਦਾ ਹੈ ("ਕੀ ਬੱਗ ਡ੍ਰਾਈਵਰ ਵਿੱਚ ਹੈ, IPC ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਹੈ ਜਾਂ ਸਰਵਰ ਵਿੱਚ?"). MINIX ਇਹ ਲਾਗਤਾਂ ਦਿਖਾਉਂਦਾ ਹੈ—ਤਾਂ ਜੋ ਵਿਦਿਆਰਥੀ ਸਿੱਖ ਸਕਣ ਕਿ fault isolation ਇੱਕ ਸੁਨੇਹਾ ਨਹੀਂ, ਬਲਕਿ ਇਕ ਜਾਣ-ਭੂਝ ਕੇ ਕੀਤਾ ਗਿਆ ਟਰੇਡਆਫ਼ ਹੈ।
ਪ੍ਰਸਿੱਧ MINIX vs Linux ਚਰਚਾ ਅਕਸਰ ਨਿੱਜੀ ਟਕਰਾਅ ਵਾਂਗ ਯਾਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਵਧੀਆ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਨੂੰ ਇਕ ਆਰਕੀਟੈਕਚਰਲ ਚਰਚਾ ਵਜੋਂ ਦੇਖੋ: ਇੱਕ ਓਐਸ ਕਿਸ ਲਈ ਅਨੁਕੂਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਿਹੜੀਆਂ ਸਹਿਯੋਗਤਾਵਾਂ ਮਨਜ਼ੂਰ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ?
MINIX ਮੁੱਖ ਤੌਰ 'ਤੇ ਇੱਕ ਟੀਚਿੰਗ ਓਐਸ ਵਜੋਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸਦੀ ਸੰਰਚਨਾ ਕਰਨਲ ਧਾਰਣਾਵਾਂ ਨੂੰ ਕਲਾਸਰੂਮ ਵਿੱਚ ਵਿਜ਼ੀਬਲ ਅਤੇ ਟੈਸਟ ਕਰਨਯੋਗ ਬਣਾਉਂਦੀ: ਛੋਟੇ ਕੰਪੋਨੈਂਟ, ਸਾਫ਼ ਹੱਦਾਂ, ਅਤੇ ਵਰਤਾਰਾ ਜੋ ਤੁਸੀਂ ਤਰਕ ਨਾਲ ਸਮਝ ਸਕਦੇ ਹੋ।
Linux ਇੱਕ ਵੱਖਰਾ ਟੀਚਾ ਰੱਖਦਾ ਸੀ: ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਸਿਸਟਮ ਜੋ ਲੋਕ ਚਲਾ ਸਕਣ, ਤੇਜ਼ੀ ਨਾਲ ਵਧਾ ਸਕਣ ਅਤੇ ਅਸਲ ਹਾਰਡਵੇਅਰ 'ਤੇ ਪੇਰਫਾਰਮ ਕਰੇ। ਇਹ ਪ੍ਰਾਇਰਟੀਜ਼ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਵੱਖਰੀਆਂ ਡਿਜ਼ਾਇਨ ਚੋਣਾਂ ਨੂੰ ਜਨਮ ਦਿੰਦੀਆਂ ਹਨ।
ਇਸ ਬਹਿਸ ਨੇ ਇਕ ਸੈੱਟ ਸਦੀਵ-ਕਾਲੀਨ ਸਵਾਲ ਉਠਾਏ:
ਟੈਨਨਬਾਊਮ ਦੀ ਨਜ਼ਰ ਤੋਂ, ਤੁਸੀਂ ਇੰਟਰਫੇਸ, ਆਇਸੋਲੇਸ਼ਨ, ਅਤੇ ਕਰਨल ਨੂੰ ਸਮਝਣ ਲਈ ਛੋਟਾ ਰੱਖਣ ਦੀ ਅਨੁਸ਼ਾਸਨ ਦੀ ਇਜ਼ਤ ਕਰਨਾ ਸਿੱਖਦੇ ਹੋ।
Linux ਵਾਲੇ ਰਸਤੇ ਤੋਂ, ਤੁਸੀਂ ਸਿੱਖਦੇ ਹੋ ਕਿ ਅਸਲ-ਦੁਨੀਆ ਦੀਆਂ ਪਾਬੰਦੀਆਂ (ਹਾਰਡਵੇਅਰ ਸਹਿਯੋਗ, ਡਿਵੈਲਪਰ ਤੇਜ਼ੀ, ਅਤੇ ਜਲਦੀ ਕੁਝ ਚਲਾਉਣ ਦੇ ਫਾਇਦੇ) ਡਿਜ਼ਾਇਨਾਂ 'ਤੇ ਕਿਵੇਂ ਦਬਾਅ ਪਾਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਆਮ ਮਿਥ ਇਹ ਹੈ ਕਿ ਇਹ ਬਹਿਸ "ਸਾਬਤ ਕਰਦੀ" ਹੈ ਕਿ ਇੱਕ ਆਰਕੀਟੈਕਚਰ ਹਮੇਸ਼ਾ ਬਿਹਤਰ ਹੈ। ਐਸਾ ਨਹੀਂ ਹੋਇਆ। ਇਸਨੇ ਇਹ ਦਰਸਾਇਆ ਕਿ ਸਿੱਖਿਆ ਵਾਲੇ ਟੀਚੇ ਅਤੇ ਉਤਪਾਦ ਵਾਲੇ ਟੀਚੇ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਸਮਝਦਾਰ ਇੰਜੀਨੀਅਰ ਵੱਖ-ਵੱਖ ਪਾਬੰਦੀਆਂ ਤੋਂ ਇਮਾਨਦਾਰ ਤਰੀਕੇ ਨਾਲ ਦਲੀਲ ਕਰ ਸਕਦੇ ਹਨ। ਇਹੀ ਸਿਖਲੀ ਕੀਮਤੀ ਗੱਲ ਹੈ।
MINIX ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ "ਉਤਪਾਦ" ਵਾਂਗ ਨਹੀਂ, ਬਲਕਿ ਇੱਕ ਲੈਬ ਔਜ਼ਾਰ ਵਾਂਗ ਸਿਖਾਇਆ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ ਇਸਨੂੰ ਵਰਤਕੇ ਇੱਕ ਅਸਲ ਕਰਨਲ ਵਿੱਚ ਕਾਰਨ-ਅਤੇ-ਪਰਭਾਵ ਦੇਖਦੇ ਹੋ ਬਿਨਾਂ ਅਣਜਾਣੀ ਜਟਿਲਤਾ ਵਿਚ ਡੁੱਬੇ। ਇੱਕ ਆਮ ਕੋਰਸ ਵਰਕਫਲੋ ਤਿੰਨ ਗਤੀਵਿਧੀਆਂ 'ਤੇ ਘੁੰਮਦਾ ਹੈ—ਪੜ੍ਹੋ, ਬਦਲੋ, ਜਾਂਚੋ—ਜਦ ਤੱਕ ਤੁਸੀਂ ਅਨੁਭਵ ਨਹੀਂ ਬਣਾ ਲੈਂਦੇ।
ਵਿਦਿਆਰਥੀ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਇਕਾਈ ਕਾਰਵਾਈ ਨੂੰ end-to-end ਟ੍ਰੇਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ: "ਇੱਕ ਪ੍ਰੋਗਰਾਮ OS ਨੂੰ ਕਿਸੇ ਫਾਈਲ ਨੂੰ ਖੋਲ੍ਹਣ ਲਈ ਕਹਿੰਦਾ ਹੈ" ਜਾਂ "ਇੱਕ ਪ੍ਰੋਸੈਸ ਸੌਣ ਲਈ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਜਾਗਦਾ ਹੈ")। ਮਕਸਦ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ ਸਭ ਮੋਡੀਊਲ ਯਾਦ ਕਰ ਲਏ; ਮਕਸਦ ਇਹ ਹੈ ਕਿ ਪਤਾ ਲੱਗੇ ਕਿ ਕਿੱਥੇ ਫੈਸਲੇ ਕੀਤੇ ਜਾ ਰਹੇ ਹਨ, ਕਿੱਥੇ ਡੇਟਾ ਚੈੱਕ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਿਹੜਾ ਕੰਪੋਨੈਂਟ ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।
ਇੱਕ ਅਮਲੀ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇੱਕ ਐਂਟ੍ਰੀ ਪੌਇੰਟ (ek syscall handler, scheduling decision, ਜਾਂ IPC message) ਚੁਣੋ ਅਤੇ ਉਸਨੂੰ ਉਸ ਸਮੇਂ ਤੱਕ ਫੋਲੋ ਕਰੋ ਜਦ ਤੱਕ ਨਤੀجہ ਦਿਸਦਾ ਨਾ ਹੋਵੇ—ਜਿਵੇਂ ਰਿਟਰਨ ਕੀਤਾ error code, ਬਦਲਿਆ process state, ਜਾਂ message reply।
ਚੰਗੇ ਸ਼ੁਰੂਆਤੀ ਕਸਰਤ ਆਮ ਤੌਰ 'ਤੇ ਸਖਤ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ:
ਕੁੰਜੀ ਇਹ ਹੈ ਕਿ ਬਦਲਾਅ ਉਹੋ ਹੋਣ ਜੋ ਸੋਚਣ ਵਿੱਚ ਆਸਾਨ ਹੋਣ ਅਤੇ “ਅਕਸਮਾਤ ਸਫਲ” ਹੋਣਾ ਮੁਸ਼ਕਲ ਹੋਵੇ।
“ਕਾਮਯਾਬੀ” ਇਹ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਅਪੇਖਾ ਕਰ ਸਕੋ ਕਿ ਤੁਹਾਡਾ ਬਦਲਾਅ ਕੀ ਕਰੇਗਾ, ਫਿਰ ਉਸ ਨੂੰ ਦੁਹਰਾਊ ਟੈਸਟਾਂ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ (ਅਤੇ ਲੋਚ ਜਦ ਲੋੜ ਹੋਵੇ)। ਅਧਿਆਪਕ ਅਕਸਰ ਪੈਚ ਤੋਂ ਜ਼ਿਆਦਾ ਉਸ ਦੀ ਵਿਆਖਿਆ ਨੂੰ ਗਰੇਡ ਕਰਦੇ ਹਨ: ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ, ਇਹ ਕਿਉਂ ਕੰਮ ਕੀਤਾ, ਅਤੇ ਇਸਨੇ ਕਿਹੜੇ ਟਰੇਡਆਫ਼ ਪੈਦਾ ਕੀਤੇ।
ਪਹਿਲਾਂ ਇੱਕ ਪਾਥ end-to-end ਟ੍ਰੇਸ ਕਰੋ, ਫਿਰ ਨੇੜਲੇ ਰਾਹਾਂ ਤੇ ਫੈਲਾਓ। ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਹੀ ਸਬ-ਸਿਸਟਮਾਂ ਦੇ ਵਿਚਕਾਰ ਜਾਓਗੇ, ਤਾਂ ਤੁਸੀਂ ਜਾਣਕਾਰੀਆਂ ਇਕੱਤਰ ਕਰ ਲਵੋਗੇ ਪਰ ਇਕ ਵਰਤਣਯੋਗ ਮਾਨਸਿਕ ਮਾਡਲ ਬਣਾਉਣ ਵਿੱਚ ਨਾਕਾਮ ਰਹੋਗੇ।
MINIX ਦੀ ਟਿਕਾਊ ਮੁੱਲ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਸੀਂ ਇਸਦੇ ਕੰਪੋਨੈਂਟ ਯਾਦ ਕਰ ਲੋ—ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਆਦਤ ਦਿਨਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਹੱਦਾਂ ਵਿੱਚ ਸੋਚੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਅੰਦਰੂਨੀ ਕਰ ਲੈਂਦੇ ਹੋ ਕਿ ਸਿਸਟਮ ਜਿੰਮੀਦਾਰੀਆਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੇ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਕੋਡਬੇਸ ਵਿੱਚ ਛੁਪੇ coupling (ਅਤੇ ਖਤਰੇ) ਨੂੰ ਵੇਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿਓਗੇ।
ਪਹਿਲਾ: ਸੰਰਚਨਾ ਚਮਕਦਾਰ ਤਰਕੀਬਾਂ ਤੋਂ ਵਧਕੇ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਬਾਕਸ ਡਾਇਗਰਾਮ ਖਿੱਚ ਸਕਦੇ ਹੋ ਜੋ ਇੱਕ ਮਹੀਨੇ ਬਾਅਦ ਵੀ ਸਮਝ ਆਵੇ, ਤਾਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਤੋਂ ਅੱਗੇ ਹੋ।
ਦੂਜਾ: ਇੰਟਰਫੇਸਾਂ ਵਿੱਚ ਸਹੀਅਤ ਵੱਸਦੀ ਹੈ। ਜਦ ਗੱਲਬਾਤ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਫੇਲ ਮੋਡ, ਪਰਮੀਸ਼ਨ ਅਤੇ ਪੇਰਫਾਰਮੈਂਸ ਬਾਰੇ ਸੋਚ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਹਰ ਲਾਈਨ ਪੜ੍ਹਨ ਦੇ।
ਤੀਜਾ: ਹਰ ਡਿਜ਼ਾਇਨ ਇੱਕ ਟਰੇਡਆਫ਼ ਹੈ। ਤੇਜ਼ ਹੋਣਾ ਹਮੇਸ਼ਾ ਚੰਗਾ ਨਹੀਂ; ਸਪਸ਼ਟਤਾ ਹਮੇਸ਼ਾ ਸੁਰੱਖਿਅਤ ਨਹੀਂ। MINIX ਦੀ ਸਿੱਖਣ-ਕੇਂਦਰਤ ਧਾਰਣਾ ਤੁਹਾਨੂੰ ਇਹ ਅਭਿਆਸ ਕਰਵਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਹਰ ਫੈਸਲੇ ਦਾ ਨਾਮ ਲਵੋ ਅਤੇ ਉਸਦਾ ਵਕਾਲਤ ਕਰੋ।
ਇਸ ਮਨੋਭਾਵ ਨੂੰ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਵਰਤੋ: ਲੱਛਣਾਂ ਦੀ ਤਲਾਸ਼ ਕਰਨ ਦੇ ਬਦਲੇ ਪੁੱਛੋ “ਕਿਹੜੀ ਹੱਦ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਪਾਰ ਹੋਈ?” ਫਿਰ ਇੰਟਰਫੇਸ 'ਤੇ ਧਾਰਨਾਵਾਂ ਦੀ ਜਾਂਚ ਕਰੋ: ਇਨਪੁੱਟ, ਆਉਟਪੁੱਟ, ਟਾਈਮਆਉਟ, ਅਤੇ ਐਰਰ ਹੈਂਡਲਿੰਗ।
ਅਰਕੀਟੈਕਚਰ ਸਮੀਖਿਆਵਾਂ ਵਿੱਚ ਵਰਤੋ: ਜਿੰਮੀਦਾਰੀਆਂ ਨੂੰ ਲਿਸਟ ਕਰੋ, ਫਿਰ ਪੋڇੋ ਕਿ ਕੋਈ ਕੰਪੋਨੇਟ ਦੂਜੇ ਬਾਰੇ ਬਹੁਤ ਜਾਣਦਾ ਤਾਂ ਨਹੀਂ। ਜੇ ਕਿਸੇ ਮੋਡੀਊਲ ਨੂੰ ਬਦਲਣ ਲਈ ਪੰਜ ਹੋਰਾਂ ਨੂੰ ਛੇੜਨਾ ਪੈਂਦਾ ਹੈ, ਤਾਂ ਹੱਦ ਸੰਭਵਤ: ਗਲਤ ਹੈ।
ਇਹ ਆਖਰਕਾਰ ਆਧੁਨਿਕ “vibe-coding” ਵਰਕਫਲੋਜ਼ ਲਈ ਵੀ ਲਾਭਕਾਰੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Koder.ai ਵਿੱਚ ਤੁਸੀਂ ਚੈਟ ਵਿੱਚ ਇੱਕ ਐਪ ਦਾ ਵਰਣਨ ਕਰਕੇ React ਫਰੰਟਐਂਡ, Go ਬੈਕਐਂਡ, ਅਤੇ PostgreSQL ਡੇਟਾਬੇਸ ਜਨਰੇਟ ਕਰਵਾ ਸਕਦੇ ਹੋ। ਚੰਗੇ ਨਤੀਜੇ ਲਈ ਸਭ ਤੋਂ ਤੇਜ਼ ਰਸਤਾ ਹੈ MINIX-ਨੁਮਾ: ਪਹਿਲਾਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰੋ (UI vs API vs ਡੇਟਾ), ਕੰਟਰੈਕਟ ਸਪਸ਼ਟ ਬਣਾਓ (ਏਂਡਪੌਇੰਟ, ਸੁਨੇਹੇ, ਐਰਰ ਕੇਸ) ਅਤੇ planning mode + snapshots/rollback ਨਾਲ ਸੁਰੱਖਿਅਤ ਤੌਰ 'ਤੇ ਦੁਹਰਾਓ।
ਜੇ ਤੁਸੀਂ ਮਾਡਲ ਨੂੰ ਡੂੰਘਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਵਿਸ਼ੇ ਅਗਲੇ ਪੱਧਰ ਲਈ ਪੜ੍ਹੋ:
ਤੁਹਾਨੂੰ ਕਰਨਲ ਇੰਜੀਨੀਅਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ MINIX ਤੋਂ ਲਿਆਭੁਟ ਪ੍ਰਾਪਤ ਕਰੋ। ਮੁੱਖ ਆਦਤ ਸਧਾਰਨ ਹੈ: ਸਿਸਟਮਾਂ ਨੂੰ ਐਸੇ ਭਾਗਾਂ ਵਜੋਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਇਕ ਦੂਜੇ ਨਾਲ ਸਪਸ਼ਟ ਕੰਟਰੈਕਟਾਂ ਰਾਹੀਂ ਸਹਿਯੋਗ ਕਰਦੇ ਹਨ—ਅਤੇ ਜੋ ਚੋਣਾਂ ਤੇ ਟਰੇਡਆਫ਼ ਉਹ ਬਣਾਉਂਦੀਆਂ ਹਨ ਉਹਨਾਂ ਨੂੰ ਆਂਕੋ।
MINIX ਜਾਣ-ਬੂਝ ਕੇ ਛੋਟਾ ਅਤੇ “inspectable” ਬਣਾਇਆ ਗਿਆ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰਤੀਕ ਤੋਂ ਅਸਲੀ ਸੋਰਸ ਕੋਡ ਤੱਕ ਇੱਕ ਧਾਰਣਾ ਦੀ ਪੱਛਾਣ ਕਰ ਸਕੋ ਬਿਨਾਂ ਮਿਲੀਅਨਾਂ ਲਾਈਨਾਂ ਦੀ ਕੋਡ ਵਿੱਚ ਡੁੱਬੇ ਹੋਏ। ਇਸ ਨਾਲ ਮੁੱਖ ਕਰਨਲ ਜ਼ਿੰਮੇਵਾਰੀਆਂ—ਸੈਡੂਲਿੰਗ, ਮੈਮੋਰੀ ਪ੍ਰੋਟੈਕਸ਼ਨ, IPC, ਅਤੇ ਡਿਵਾਈਸ ਐਕਸੈਸ—ਨੂੰ ਇੱਕ ਸੈਮੈਸਟਰ ਵਿੱਚ ਪੜ੍ਹਨਾ ਅਤੇ ਸੋਧਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇੱਕ teaching OS ਵੱਧ ਤੋਂ ਵੱਧ ਪੇਰਫਾਰਮੈਂਸ ਜਾਂ ਵੱਡੇ ਹਾਰਡਵੇਅਰ ਸਹਿਯੋਗ ਦੇ ਬਦਲੇ ਸਪਸ਼ਟਤਾ ਅਤੇ ਪ੍ਰਯੋਗਸ਼ੀਲਤਾ ਨੂੰ ਤਰਜੀਹ ਦਿੰਦਾ ਹੈ। ਇਸ ਦਾ ਅਰਥ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟਾ ਕੋਡਬੇਸ, ਸਥਿਰ ਇੰਟਰਫੇਸ, ਅਤੇ atructure ਹੁੰਦੀ ਹੈ ਜੋ ਪਾਠਕਾਂ ਨੂੰ ਸਿਸਟਮ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਪੜ੍ਹਨ, ਬਦਲਨ ਅਤੇ ਟੈਸਟ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ।
ਮਾਈਕਰੋਕਰਨਲ ਉਹ ਹੈ ਜੋ ਕਰਨਲ ਨੂੰ ਇਰਾਦੇ ਨਾਲ ਛੋਟਾ ਰੱਖਦਾ ਹੈ। MINIX ਵਿੱਚ ਮਾਈਕਰੋਕਰਨਲ ਵਿੱਚ ਸਿਰਫ਼ ਉਹੀ ਮਕਰਦਾਰ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪੂਰੇ ਹਾਰਡਵੇਅਰ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਹੈ, ਉਦਾਹਰਨ ਲਈ:
ਬਾਕੀ ਸਾਰੇ (ਫਾਈਲ ਸਿਸਟਮ, ਡ੍ਰਾਈਵਰ, ਬਹੁਤ ਸੇ ਸੇਵਾ) ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਸੈਸਾਂ ਵਜੋਂ ਚੱਲਦੇ ਹਨ ਜੋ ਮੇਸੇਜਾਂ ਰਾਹੀਂ ਗੱਲ ਕਰਦੇ ਹਨ।
ਮਾਈਕਰੋਕਰਨਲ ਡਿਜ਼ਾਈਨ ਵਿੱਚ, ਕਈ OS ਕੰਪੋਨੇਟ ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਸੈਸਾਂ ਹੁੰਦੇ ਹਨ। ਅੰਦਰੂਨੀ kernel ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੰਪੋਨੇਟ ਰਚਨਾ ਕੀਤਾ ਹੋਇਆ IPC ਸੁਨੇਹਾ ਭੇਜਦੇ ਹਨ—ਜਿਵੇਂ "ਇਹ ਬਾਈਟ ਪੜ੍ਹੋ" ਜਾਂ "ਇਹ ਬਲੌਕ ਲਿਖੋ"—ਫਿਰ ਜਵਾਬ ਦੀ ਉਡੀਕ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਉਸ ਨੂੰ ਹੈਂਡਲ ਕਰਦੇ ਹਨ। ਇਹ ਵਿਧੀ ਸਪਸ਼ਟ ਇੰਟਰਫੇਸਾਂ ਨੂੰ ਬਲਾਇਤਾ ਕਰਦੀ ਹੈ ਅਤੇ ਛੁਪੇ ਹੋਏ ਸਾਂਝੇ ਰਾਜ (shared state) ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ।
ਇੱਕ ਆਮ ਪਾਥ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
read) ਕਰਦਾ ਹੈ।ਇੱਕ ਐਂਡ-ਟੁ-ਐਂਡ ਟ੍ਰੇਸ ਕਰਨ ਨਾਲ ਇੱਕ ਪ੍ਰਯੋਗਕਾਰੀ ਮਾਨਸਿਕ ਨਕਸ਼ਾ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
ਇੱਕ ਆਮ ਫ੍ਰੇਮਿੰਗ ਇਹ ਹੈ:
MINIX ਇਹ ਅਲੱਗੀਆਂ ਵਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਯੂਜ਼ਰ-ਸਪੇਸ ਵਿੱਚ ਨੀਤੀਆਂ ਬਦਲ ਸਕੋ ਬਿਨਾਂ ਸਭ ਤੋਂ ਭਰੋਸੇਯੋਗ kernel ਕੋਰ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੇ।
ਸਿੰਗਕ੍ਰੋਨਸ IPC ਦਾ مطلب ਹੈ ਭੇਜਣ ਵਾਲਾ ਜਵਾਬ ਦੇਣ ਤੱਕ ਉਡੀਕ ਕਰਦਾ ਹੈ (सरਲ ਫਲੋ, ਅਸਾਨ ਤਰਕ)। ਅਸਿੰਗਕ੍ਰੋਨਸ IPC ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਅੱਗੇ ਕੰਮ ਕਰਨ ਦਿੰਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਬਾਅਦ ਵਿੱਚ ਮਿਲਦਾ ਹੈ (ਵੱਧ concurrency, ਪਰ pending requests, ordering ਅਤੇ timeouts ਦਾ ਪ੍ਰਬੰਧ ਕਰਨਾ ਪੈਂਦਾ ਹੈ)। ਸਿੱਖਣ ਲਈ, ਸਿੰਗਕ੍ਰੋਨਸ ਫਲੋ ਅਕਸਰ ਐਂਡ-ਟੁ-ਐਂਡ ਟ੍ਰੇਸ ਕਰਨ ਲਈ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।
ਮਾਈਕਰੋਕਰਨਲ ਆਮ ਤੌਰ 'ਤੇ ਹਾਸਿਲ ਕਰਦੇ ਹਨ:
ਪਰ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਭੁਗਤਦੇ ਹਨ:
MINIX ਉਭਾਰ ਕੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਦੋਹਾਂ ਪਾਸੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ।
ਡ੍ਰਾਈਵਰਾਂ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਹਾਰਡਵੇਅਰ-ਨਿਰਪੇਕ ਕੋਡ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹ crashes ਦੇ ਇੱਕ ਮੁੱਖ ਸਰੋਤ ਹੁੰਦੇ ਹਨ। MINIX ਵਿੱਚ ਡ੍ਰਾਈਵਰਾਂ ਨੂੰ ਯੂਜ਼ਰ-ਸਪੇਸ ਪ੍ਰੋਸੈਸ ਵਜੋਂ ਚਲਾਕੇ:
ਲਾਗਤ: ਵੱਧ IPC ਅਤੇ ਡ੍ਰਾਈਵਰ ਇੰਟਰਫੇਸਾਂ ਦੀ ਹਥਿਆਰਬੰਦੀ (design) ਦੀ ਲੋੜ।
ਹੇਠਾਂ ਇੱਕ ਪ੍ਰਾਇਗਟਿਕੀ workflow ਹੈ:
ਛੋਟੀਆਂ ਤਬਦੀਲੀਆਂ ਰੱਖਣ ਨਾਲ ਤੁਸੀਂ ਕਾਰਨ-ਅਤੇ-ਪਰਭਾਵ ਸਿੱਖੋਗੇ, ਨਾ ਕਿ ਇੱਕ ਵੱਡੇ ਅਸਪਸ਼ਟ ਪੈਚ ਨੂੰ ਡੀਬੱਗ ਕਰਦੇ ਹੋਏ ਖੋ ਜਾਵੋਗੇ।