ਯੂਨਿਕਸ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਇਹ ਲੇਖ ਯੂਨਿਕਸ ਕਰਨਲ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਮੈਂ ਥੋੜਾ ਨਿਰਾਸ਼ ਸੀ ਕਿ ਇੱਕ ਤਾਜ਼ਾ ਲੇਖ ਜਿਸਦਾ ਸਿਰਲੇਖ ਹੈ "ਯੂਨਿਕਸ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ?" ਨਿਕਲਿਆ ਨਾ ਅੰਦਰੂਨੀ ਬਣਤਰ ਬਾਰੇ. ਮੈਂ ਉਤਸੁਕ ਹੋ ਗਿਆ ਅਤੇ ਜਵਾਬ ਲੱਭਣ ਲਈ ਪੁਰਾਣੇ ਸਰੋਤਾਂ ਨੂੰ ਖੋਦਿਆ।

ਅਸੀਂ ਕਿਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ?

ਪਾਈਪਲਾਈਨਾਂ, "ਸ਼ਾਇਦ ਯੂਨਿਕਸ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਾਢ," ਛੋਟੇ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਆਪਸ ਵਿੱਚ ਜੋੜਨ ਦੇ ਅੰਤਰੀਵ ਯੂਨਿਕਸ ਫ਼ਲਸਫ਼ੇ ਦੀ ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਅਤੇ ਨਾਲ ਹੀ ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ ਇੱਕ ਜਾਣੂ ਚਿੰਨ੍ਹ ਹੈ:

$ echo hello | wc -c
6

ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਕਰਨਲ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਸਿਸਟਮ ਕਾਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ pipe, ਜਿਸਦਾ ਵਰਣਨ ਦਸਤਾਵੇਜ਼ੀ ਪੰਨਿਆਂ 'ਤੇ ਕੀਤਾ ਗਿਆ ਹੈ ਪਾਈਪ(7) и ਪਾਈਪ(2):

ਪਾਈਪਲਾਈਨਾਂ ਇੰਟਰਪ੍ਰੋਸੈਸ ਸੰਚਾਰ ਲਈ ਇੱਕ ਦਿਸ਼ਾਹੀਣ ਚੈਨਲ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ। ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਇੱਕ ਇਨਪੁਟ (ਐਂਡ ਲਿਖੋ) ਅਤੇ ਇੱਕ ਆਉਟਪੁੱਟ (ਐਂਡ ਪੜ੍ਹੋ) ਹੈ। ਪਾਈਪਲਾਈਨ ਦੇ ਇੰਪੁੱਟ ਨੂੰ ਲਿਖਿਆ ਡਾਟਾ ਆਉਟਪੁੱਟ 'ਤੇ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ.

ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਈਪਲਾਈਨ ਬਣਾਈ ਗਈ ਹੈ pipe(2), ਜੋ ਕਿ ਦੋ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਹੈ: ਇੱਕ ਪਾਈਪਲਾਈਨ ਦੇ ਇੰਪੁੱਟ ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ, ਦੂਜਾ ਆਉਟਪੁੱਟ ਦਾ।

ਉਪਰੋਕਤ ਕਮਾਂਡ ਤੋਂ ਟਰੇਸ ਆਉਟਪੁੱਟ ਪਾਈਪਲਾਈਨ ਦੀ ਸਿਰਜਣਾ ਅਤੇ ਇਸਦੇ ਦੁਆਰਾ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਦੂਜੀ ਤੱਕ ਡੇਟਾ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ:

$ strace -qf -e execve,pipe,dup2,read,write 
    sh -c 'echo hello | wc -c'

execve("/bin/sh", ["sh", "-c", "echo hello | wc -c"], …)
pipe([3, 4])                            = 0
[pid 2604795] dup2(4, 1)                = 1
[pid 2604795] write(1, "hellon", 6)    = 6
[pid 2604796] dup2(3, 0)                = 0
[pid 2604796] execve("/usr/bin/wc", ["wc", "-c"], …)
[pid 2604796] read(0, "hellon", 16384) = 6
[pid 2604796] write(1, "6n", 2)        = 2

ਮਾਤਾ-ਪਿਤਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਾਲ ਕਰਦੀ ਹੈ pipe()ਮਾਊਂਟ ਕੀਤੇ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ. ਇੱਕ ਬਾਲ ਪ੍ਰਕਿਰਿਆ ਇੱਕ ਹੈਂਡਲ ਨੂੰ ਲਿਖਦੀ ਹੈ, ਅਤੇ ਦੂਜੀ ਪ੍ਰਕਿਰਿਆ ਦੂਜੇ ਹੈਂਡਲ ਤੋਂ ਉਹੀ ਡੇਟਾ ਪੜ੍ਹਦੀ ਹੈ। ਸ਼ੈੱਲ stdin ਅਤੇ stdout ਨਾਲ ਮੇਲ ਕਰਨ ਲਈ ਵਰਣਨਕਰਤਾ 2 ਅਤੇ 3 ਨੂੰ "ਰਿਨਾਮ" ਕਰਨ ਲਈ dup4 ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਪਾਈਪਾਂ ਤੋਂ ਬਿਨਾਂ, ਸ਼ੈੱਲ ਨੂੰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਦਾ ਆਉਟਪੁੱਟ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਲਿਖਣਾ ਪਏਗਾ ਅਤੇ ਫਾਈਲ ਤੋਂ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਇਸਨੂੰ ਦੂਜੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਪਾਸ ਕਰਨਾ ਹੋਵੇਗਾ। ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਹੋਰ ਸਰੋਤ ਅਤੇ ਡਿਸਕ ਸਪੇਸ ਬਰਬਾਦ ਕਰਾਂਗੇ। ਹਾਲਾਂਕਿ, ਪਾਈਪਲਾਈਨਾਂ ਨਾ ਸਿਰਫ ਚੰਗੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਤੁਹਾਨੂੰ ਅਸਥਾਈ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਤੋਂ ਬਚਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ:

ਜੇਕਰ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਖਾਲੀ ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੀ ਹੈ ਤਾਂ read(2) ਡਾਟਾ ਉਪਲਬਧ ਹੋਣ ਤੱਕ ਬਲੌਕ ਕੀਤਾ ਜਾਵੇਗਾ। ਜੇਕਰ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਪੂਰੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੀ ਹੈ, ਤਾਂ write(2) ਉਦੋਂ ਤੱਕ ਬਲੌਕ ਕੀਤਾ ਜਾਵੇਗਾ ਜਦੋਂ ਤੱਕ ਲਿਖਣ ਲਈ ਪਾਈਪਲਾਈਨ ਤੋਂ ਕਾਫ਼ੀ ਡੇਟਾ ਪੜ੍ਹਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ।

POSIX ਲੋੜਾਂ ਵਾਂਗ, ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ: ਪਾਈਪਲਾਈਨ ਤੱਕ ਲਿਖਣਾ PIPE_BUF ਬਾਈਟਸ (ਘੱਟੋ-ਘੱਟ 512) ਪਰਮਾਣੂ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਜੋ ਪ੍ਰਕਿਰਿਆਵਾਂ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਚਾਰ ਕਰ ਸਕਣ ਕਿ ਨਿਯਮਤ ਫਾਈਲਾਂ (ਜੋ ਅਜਿਹੀਆਂ ਗਰੰਟੀਆਂ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀਆਂ) ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ।

ਇੱਕ ਨਿਯਮਤ ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਇਸਦੇ ਸਾਰੇ ਆਉਟਪੁੱਟ ਨੂੰ ਇਸ ਵਿੱਚ ਲਿਖ ਸਕਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਭੇਜ ਸਕਦੀ ਹੈ. ਜਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਬਹੁਤ ਹੀ ਸਮਾਨਾਂਤਰ ਮੋਡ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਇੱਕ ਬਾਹਰੀ ਸਿਗਨਲ ਵਿਧੀ (ਜਿਵੇਂ ਇੱਕ ਸੈਮਾਫੋਰ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਦੂਜੇ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਲਈ ਜਦੋਂ ਇੱਕ ਲਿਖਣਾ ਜਾਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ। ਕਨਵੇਅਰ ਸਾਨੂੰ ਇਸ ਸਾਰੀ ਪਰੇਸ਼ਾਨੀ ਤੋਂ ਬਚਾਉਂਦੇ ਹਨ।

ਅਸੀਂ ਕੀ ਲੱਭ ਰਹੇ ਹਾਂ?

ਮੈਂ ਇਸਨੂੰ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਵਿਆਖਿਆ ਕਰਾਂਗਾ ਤਾਂ ਜੋ ਤੁਹਾਡੇ ਲਈ ਇਹ ਕਲਪਨਾ ਕਰਨਾ ਆਸਾਨ ਹੋਵੇ ਕਿ ਇੱਕ ਕਨਵੇਅਰ ਕਿਵੇਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਬਫਰ ਅਤੇ ਕੁਝ ਰਾਜ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਤੁਹਾਨੂੰ ਬਫਰ ਤੋਂ ਡਾਟਾ ਜੋੜਨ ਅਤੇ ਹਟਾਉਣ ਲਈ ਫੰਕਸ਼ਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਤੁਹਾਨੂੰ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ 'ਤੇ ਰੀਡ ਅਤੇ ਰਾਈਟ ਓਪਰੇਸ਼ਨਾਂ ਦੌਰਾਨ ਫੰਕਸ਼ਨਾਂ ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਕੁਝ ਸਾਧਨਾਂ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਅਤੇ ਤੁਹਾਨੂੰ ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਿਸ਼ੇਸ਼ ਵਿਵਹਾਰ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਤਾਲੇ ਦੀ ਲੋੜ ਪਵੇਗੀ।

ਹੁਣ ਅਸੀਂ ਆਪਣੇ ਅਸਪਸ਼ਟ ਮਾਨਸਿਕ ਮਾਡਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਜਾਂ ਗਲਤ ਸਾਬਤ ਕਰਨ ਲਈ ਚਮਕਦਾਰ ਲੈਂਪਲਾਈਟ ਦੇ ਅਧੀਨ ਕਰਨਲ ਸਰੋਤ ਕੋਡ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ। ਪਰ ਹਮੇਸ਼ਾ ਅਚਾਨਕ ਲਈ ਤਿਆਰ ਰਹੋ.

ਅਸੀਂ ਕਿੱਥੇ ਦੇਖ ਰਹੇ ਹਾਂ?

ਮੈਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਮੇਰੀ ਮਸ਼ਹੂਰ ਕਿਤਾਬ ਦੀ ਕਾਪੀ ਕਿੱਥੇ ਹੈ "ਸ਼ੇਰਾਂ ਦੀ ਕਿਤਾਬਯੂਨਿਕਸ 6 ਸਰੋਤ ਕੋਡ ਦੇ ਨਾਲ, ਪਰ ਧੰਨਵਾਦ ਯੂਨਿਕਸ ਹੈਰੀਟੇਜ ਸੁਸਾਇਟੀ 'ਤੇ ਆਨਲਾਈਨ ਖੋਜ ਕਰ ਸਕਦੇ ਹੋ ਸੂਤਰ ਸੰਕੇਤਾਵਲੀ ਯੂਨਿਕਸ ਦੇ ਵੀ ਪੁਰਾਣੇ ਸੰਸਕਰਣ।

TUHS ਪੁਰਾਲੇਖਾਂ ਵਿੱਚ ਘੁੰਮਣਾ ਇੱਕ ਅਜਾਇਬ ਘਰ ਵਿੱਚ ਜਾਣ ਵਰਗਾ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਸਾਂਝੇ ਇਤਿਹਾਸ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਅਤੇ ਮੈਂ ਪੁਰਾਣੀਆਂ ਟੇਪਾਂ ਅਤੇ ਪ੍ਰਿੰਟਸ ਤੋਂ ਇਸ ਸਾਰੀ ਸਮੱਗਰੀ ਨੂੰ ਥੋੜ੍ਹਾ-ਥੋੜ੍ਹਾ ਕਰਕੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕਈ ਸਾਲਾਂ ਦੇ ਯਤਨਾਂ ਦਾ ਸਨਮਾਨ ਕਰਦਾ ਹਾਂ। ਅਤੇ ਮੈਂ ਉਨ੍ਹਾਂ ਟੁਕੜਿਆਂ ਬਾਰੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹਾਂ ਜੋ ਅਜੇ ਵੀ ਲਾਪਤਾ ਹਨ.

ਕਨਵੇਅਰਾਂ ਦੇ ਪ੍ਰਾਚੀਨ ਇਤਿਹਾਸ ਬਾਰੇ ਸਾਡੀ ਉਤਸੁਕਤਾ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਤੁਲਨਾ ਲਈ ਆਧੁਨਿਕ ਕਰਨਲ ਦੇਖ ਸਕਦੇ ਹਾਂ।

ਤਰੀਕੇ ਨਾਲ ਕਰ ਕੇ, pipe ਸਾਰਣੀ ਵਿੱਚ ਸਿਸਟਮ ਕਾਲ ਨੰਬਰ 42 ਹੈ sysent[]. ਇਤਫ਼ਾਕ?

ਰਵਾਇਤੀ ਯੂਨਿਕਸ ਕਰਨਲ (1970-1974)

ਮੈਨੂੰ ਕੋਈ ਨਿਸ਼ਾਨ ਨਹੀਂ ਮਿਲਿਆ pipe(2) ਨਾ ਹੀ ਅੰਦਰ PDP-7 ਯੂਨਿਕਸ (ਜਨਵਰੀ 1970), ਨਾ ਹੀ ਵਿੱਚ ਯੂਨਿਕਸ ਦਾ ਪਹਿਲਾ ਐਡੀਸ਼ਨ (ਨਵੰਬਰ 1971), ਨਾ ਹੀ ਅਧੂਰੇ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਦੂਜਾ ਐਡੀਸ਼ਨ (ਜੂਨ 1972)।

TUHS ਕਹਿੰਦਾ ਹੈ ਕਿ ਯੂਨਿਕਸ ਦਾ ਤੀਜਾ ਐਡੀਸ਼ਨ (ਫਰਵਰੀ 1973) ਕਨਵੇਅਰ ਨਾਲ ਪਹਿਲਾ ਸੰਸਕਰਣ ਬਣ ਗਿਆ:

ਯੂਨਿਕਸ ਤੀਸਰਾ ਐਡੀਸ਼ਨ ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਕਰਨਲ ਵਾਲਾ ਆਖਰੀ ਸੰਸਕਰਣ ਸੀ, ਪਰ ਪਾਈਪਲਾਈਨਾਂ ਵਾਲਾ ਪਹਿਲਾ ਸੰਸਕਰਣ ਵੀ ਸੀ। 1973 ਦੇ ਦੌਰਾਨ, ਤੀਜੇ ਐਡੀਸ਼ਨ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨ ਲਈ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਰਨਲ ਨੂੰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਯੂਨਿਕਸ ਦਾ ਚੌਥਾ ਸੰਸਕਰਣ ਪ੍ਰਗਟ ਹੋਇਆ।

ਇੱਕ ਪਾਠਕ ਨੂੰ ਇੱਕ ਦਸਤਾਵੇਜ਼ ਦਾ ਸਕੈਨ ਮਿਲਿਆ ਜਿਸ ਵਿੱਚ ਡੱਗ ਮੈਕਿਲਰੋਏ ਨੇ "ਬਗੀਚੇ ਦੀ ਹੋਜ਼ ਵਾਂਗ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਜੋੜਨ" ਦਾ ਵਿਚਾਰ ਪੇਸ਼ ਕੀਤਾ।

ਬ੍ਰਾਇਨ ਕੇਰਨੀਘਨ ਦੀ ਕਿਤਾਬ ਵਿੱਚਯੂਨਿਕਸ: ਇੱਕ ਇਤਿਹਾਸ ਅਤੇ ਇੱਕ ਯਾਦ", ਕਨਵੇਅਰਾਂ ਦੇ ਉਭਾਰ ਦੇ ਇਤਿਹਾਸ ਵਿੱਚ, ਇਸ ਦਸਤਾਵੇਜ਼ ਦਾ ਵੀ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਹੈ: "... ਇਹ 30 ਸਾਲਾਂ ਤੋਂ ਬੈੱਲ ਲੈਬਜ਼ ਵਿੱਚ ਮੇਰੇ ਦਫ਼ਤਰ ਵਿੱਚ ਕੰਧ 'ਤੇ ਲਟਕਿਆ ਹੋਇਆ ਹੈ।" ਇਥੇ McIlroy ਨਾਲ ਇੰਟਰਵਿਊ, ਅਤੇ ਤੋਂ ਇੱਕ ਹੋਰ ਕਹਾਣੀ ਮੈਕਿਲਰੋਏ ਦਾ ਕੰਮ, 2014 ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ:

ਜਦੋਂ ਯੂਨਿਕਸ ਬਾਹਰ ਆਇਆ, ਤਾਂ ਕੋਰੋਟੀਨ ਦੇ ਨਾਲ ਮੇਰਾ ਮੋਹ ਮੈਨੂੰ OS ਦੇ ਲੇਖਕ, ਕੇਨ ਥੌਮਸਨ ਨੂੰ ਪੁੱਛਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਸੀ, ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਲਈ ਲਿਖੇ ਡੇਟਾ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਡਿਵਾਈਸ ਵਿੱਚ ਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ, ਸਗੋਂ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ ਵੀ। ਕੇਨ ਨੇ ਫੈਸਲਾ ਕੀਤਾ ਕਿ ਇਹ ਸੰਭਵ ਸੀ. ਹਾਲਾਂਕਿ, ਇੱਕ ਘੱਟੋ-ਘੱਟ ਦੇ ਰੂਪ ਵਿੱਚ, ਉਹ ਚਾਹੁੰਦਾ ਸੀ ਕਿ ਹਰੇਕ ਸਿਸਟਮ ਫੰਕਸ਼ਨ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾ ਨਿਭਾਵੇ। ਕੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਵਿਚਕਾਰ ਸਿੱਧਾ ਲਿਖਣਾ ਇੱਕ ਇੰਟਰਮੀਡੀਏਟ ਫਾਈਲ ਨੂੰ ਲਿਖਣ ਨਾਲੋਂ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਹੈ? ਇਹ ਉਦੋਂ ਹੀ ਸੀ ਜਦੋਂ ਮੈਂ ਆਕਰਸ਼ਕ ਨਾਮ "ਪਾਈਪਲਾਈਨ" ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਲਈ ਸੰਟੈਕਸ ਦੇ ਵਰਣਨ ਨਾਲ ਇੱਕ ਖਾਸ ਪ੍ਰਸਤਾਵ ਬਣਾਇਆ ਸੀ ਜੋ ਕੇਨ ਨੇ ਅੰਤ ਵਿੱਚ ਕਿਹਾ: "ਮੈਂ ਇਹ ਕਰਾਂਗਾ!"

ਅਤੇ ਕੀਤਾ. ਇੱਕ ਭਿਆਨਕ ਸ਼ਾਮ, ਕੇਨ ਨੇ ਕਰਨਲ ਅਤੇ ਸ਼ੈੱਲ ਨੂੰ ਬਦਲਿਆ, ਕਈ ਮਿਆਰੀ ਪ੍ਰੋਗਰਾਮਾਂ ਨੂੰ ਮਿਆਰੀ ਬਣਾਉਣ ਲਈ ਫਿਕਸ ਕੀਤਾ ਕਿ ਉਹਨਾਂ ਨੇ ਇੰਪੁੱਟ ਨੂੰ ਕਿਵੇਂ ਸਵੀਕਾਰ ਕੀਤਾ (ਜੋ ਕਿ ਇੱਕ ਪਾਈਪਲਾਈਨ ਤੋਂ ਆ ਸਕਦਾ ਹੈ), ਅਤੇ ਫਾਈਲ ਦੇ ਨਾਮ ਵੀ ਬਦਲੇ। ਅਗਲੇ ਦਿਨ, ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਬਹੁਤ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਵਰਤਿਆ ਜਾਣ ਲੱਗਾ। ਹਫ਼ਤੇ ਦੇ ਅੰਤ ਤੱਕ, ਸਕੱਤਰ ਉਹਨਾਂ ਨੂੰ ਵਰਡ ਪ੍ਰੋਸੈਸਰਾਂ ਤੋਂ ਪ੍ਰਿੰਟਰ ਤੱਕ ਦਸਤਾਵੇਜ਼ ਭੇਜਣ ਲਈ ਵਰਤ ਰਹੇ ਸਨ। ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ, ਕੇਨ ਨੇ ਪਾਈਪਲਾਈਨਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਕਲੀਨਰ ਕਨਵੈਨਸ਼ਨਾਂ ਨਾਲ ਸਮੇਟਣ ਲਈ ਅਸਲੀ API ਅਤੇ ਸੰਟੈਕਸ ਨੂੰ ਬਦਲ ਦਿੱਤਾ, ਜੋ ਕਿ ਉਦੋਂ ਤੋਂ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਤੀਜੇ ਐਡੀਸ਼ਨ ਯੂਨਿਕਸ ਕਰਨਲ ਲਈ ਸਰੋਤ ਕੋਡ ਗੁੰਮ ਹੋ ਗਿਆ ਹੈ। ਅਤੇ ਹਾਲਾਂਕਿ ਸਾਡੇ ਕੋਲ ਕਰਨਲ ਸੋਰਸ ਕੋਡ C ਵਿੱਚ ਲਿਖਿਆ ਹੋਇਆ ਹੈ ਚੌਥਾ ਐਡੀਸ਼ਨ, ਨਵੰਬਰ 1973 ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਇਹ ਅਧਿਕਾਰਤ ਰਿਲੀਜ਼ ਤੋਂ ਕਈ ਮਹੀਨੇ ਪਹਿਲਾਂ ਸਾਹਮਣੇ ਆਇਆ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ ਪਾਈਪਲਾਈਨ ਲਾਗੂਕਰਨ ਸ਼ਾਮਲ ਨਹੀਂ ਹੈ। ਇਹ ਸ਼ਰਮਨਾਕ ਹੈ ਕਿ ਇਸ ਮਹਾਨ ਯੂਨਿਕਸ ਫੰਕਸ਼ਨ ਲਈ ਸਰੋਤ ਕੋਡ ਗੁੰਮ ਹੋ ਗਿਆ ਹੈ, ਸ਼ਾਇਦ ਹਮੇਸ਼ਾ ਲਈ।

ਸਾਡੇ ਕੋਲ ਟੈਕਸਟ ਦਸਤਾਵੇਜ਼ ਹਨ pipe(2) ਦੋਵਾਂ ਰੀਲੀਜ਼ਾਂ ਤੋਂ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਖੋਜ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰ ਸਕੋ ਤੀਜਾ ਐਡੀਸ਼ਨ (ਕੁਝ ਸ਼ਬਦਾਂ ਲਈ, "ਹੱਥੀਂ" ਰੇਖਾਂਕਿਤ, ਅੱਖਰਾਂ ਦੀ ਇੱਕ ਸਤਰ ^H, ਇਸਦੇ ਬਾਅਦ ਇੱਕ ਅੰਡਰਸਕੋਰ!) ਇਹ ਪ੍ਰੋਟੋ-pipe(2) ਅਸੈਂਬਲੀ ਭਾਸ਼ਾ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ ਅਤੇ ਸਿਰਫ ਇੱਕ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਪਰ ਪਹਿਲਾਂ ਹੀ ਉਮੀਦ ਕੀਤੀ ਬੁਨਿਆਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ:

ਸਿਸਟਮ ਕਾਲ ਪਾਈਪ ਪਾਈਪਲਾਈਨ ਨਾਮਕ ਇੱਕ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ ਵਿਧੀ ਬਣਾਉਂਦਾ ਹੈ। ਵਾਪਸ ਕੀਤੀ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਪਾਈਪਲਾਈਨ 'ਤੇ ਕੁਝ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ 504 ਬਾਈਟ ਤੱਕ ਦਾ ਡਾਟਾ ਬਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮੁਅੱਤਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਬਫਰਡ ਡੇਟਾ ਖੋਹ ਲਿਆ ਜਾਂਦਾ ਹੈ।

ਅਗਲੇ ਸਾਲ ਤੱਕ ਕਰਨਲ ਨੂੰ C ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਅਤੇ ਪਾਈਪ (2) ਚੌਥੇ ਐਡੀਸ਼ਨ ਵਿੱਚ ਪ੍ਰੋਟੋਟਾਈਪ ਨਾਲ ਇਸਦੀ ਆਧੁਨਿਕ ਦਿੱਖ ਪ੍ਰਾਪਤ ਕੀਤੀ "pipe(fildes)"

ਸਿਸਟਮ ਕਾਲ ਪਾਈਪ ਪਾਈਪਲਾਈਨ ਨਾਮਕ ਇੱਕ ਇਨਪੁਟ/ਆਉਟਪੁੱਟ ਵਿਧੀ ਬਣਾਉਂਦਾ ਹੈ। ਵਾਪਸ ਕੀਤੇ ਗਏ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰਾਂ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੇ ਕਾਰਜਾਂ ਵਿੱਚ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਪਾਈਪਲਾਈਨ 'ਤੇ ਕੁਝ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ r1 (resp. fildes[1]) ਵਿੱਚ ਵਾਪਸ ਆਏ ਹੈਂਡਲ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਡੇਟਾ ਦੇ 4096 ਬਾਈਟਾਂ ਵਿੱਚ ਬਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਲਿਖਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮੁਅੱਤਲ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਹੈਂਡਲ r0 (resp. fildes[0]) 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ, ਡੇਟਾ ਲੈਂਦਾ ਹੈ।

ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਪਾਈਪਲਾਈਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਦੋ (ਜਾਂ ਵੱਧ) ਸੰਚਾਰ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਇਸ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਕਾਲਾਂ ਦੁਆਰਾ ਬਣਾਈਆਂ ਗਈਆਂ ਫੋਰਕ) ਕਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਈਪਲਾਈਨ ਤੋਂ ਡਾਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰੇਗਾ ਨੂੰ ਪੜ੍ਹਨ и ਲਿਖਣ ਦੀ.

ਸ਼ੈੱਲ ਵਿੱਚ ਪਾਈਪਲਾਈਨ ਦੁਆਰਾ ਜੁੜੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਇੱਕ ਲੀਨੀਅਰ ਐਰੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਲਈ ਇੱਕ ਸੰਟੈਕਸ ਹੈ।

ਇੱਕ ਖਾਲੀ ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹਨ ਲਈ ਕਾਲਾਂ (ਜਿਸ ਵਿੱਚ ਕੋਈ ਬਫਰਡ ਡੇਟਾ ਨਹੀਂ ਹੈ) ਜਿਸਦਾ ਸਿਰਫ਼ ਇੱਕ ਸਿਰਾ ਹੈ (ਸਾਰੇ ਲਿਖਣ ਵਾਲੇ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਬੰਦ ਹਨ) "ਫਾਇਲ ਦਾ ਅੰਤ" ਵਾਪਸ ਕਰਦੇ ਹਨ। ਇੱਕ ਸਮਾਨ ਸਥਿਤੀ ਵਿੱਚ ਲਿਖਣ ਲਈ ਕਾਲਾਂ ਨੂੰ ਅਣਡਿੱਠ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸੁਰੱਖਿਅਤ ਪਾਈਪਲਾਈਨ ਲਾਗੂ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ ਯੂਨਿਕਸ ਦੇ ਪੰਜਵੇਂ ਐਡੀਸ਼ਨ ਲਈ (ਜੂਨ 1974), ਪਰ ਇਹ ਅਗਲੀ ਰੀਲੀਜ਼ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਣ ਵਾਲੇ ਇੱਕ ਵਰਗਾ ਹੀ ਹੈ। ਟਿੱਪਣੀਆਂ ਹੁਣੇ ਜੋੜੀਆਂ ਗਈਆਂ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ ਪੰਜਵੇਂ ਸੰਸਕਰਨ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹੋ।

ਯੂਨਿਕਸ ਦਾ ਛੇਵਾਂ ਐਡੀਸ਼ਨ (1975)

ਆਓ ਯੂਨਿਕਸ ਸੋਰਸ ਕੋਡ ਨੂੰ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰੀਏ ਛੇਵਾਂ ਐਡੀਸ਼ਨ (ਮਈ 1975)। ਦਾ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਧੰਨਵਾਦ ਲਾਇਨਜ਼ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਦੇ ਸਰੋਤਾਂ ਨਾਲੋਂ ਇਹ ਲੱਭਣਾ ਬਹੁਤ ਸੌਖਾ ਹੈ:

ਕਈ ਸਾਲਾਂ ਤੋਂ ਕਿਤਾਬ ਲਾਇਨਜ਼ ਬੇਲ ਲੈਬਜ਼ ਦੇ ਬਾਹਰ ਉਪਲਬਧ ਯੂਨਿਕਸ ਕਰਨਲ ਦਾ ਇੱਕੋ-ਇੱਕ ਦਸਤਾਵੇਜ਼ ਸੀ। ਹਾਲਾਂਕਿ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਦੇ ਲਾਇਸੈਂਸ ਨੇ ਅਧਿਆਪਕਾਂ ਨੂੰ ਇਸਦੇ ਸਰੋਤ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ, ਸੱਤਵੇਂ ਐਡੀਸ਼ਨ ਦੇ ਲਾਇਸੈਂਸ ਨੇ ਇਸ ਸੰਭਾਵਨਾ ਨੂੰ ਬਾਹਰ ਰੱਖਿਆ, ਇਸਲਈ ਕਿਤਾਬ ਨੂੰ ਗੈਰ-ਕਾਨੂੰਨੀ ਟਾਈਪਰਾਈਟ ਕਾਪੀਆਂ ਦੇ ਰੂਪ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ।

ਅੱਜ ਤੁਸੀਂ ਕਿਤਾਬ ਦਾ ਮੁੜ-ਪ੍ਰਿੰਟ ਖਰੀਦ ਸਕਦੇ ਹੋ, ਜਿਸ ਦਾ ਕਵਰ ਕਾਪੀ ਮਸ਼ੀਨ 'ਤੇ ਵਿਦਿਆਰਥੀਆਂ ਨੂੰ ਦਿਖਾਉਂਦਾ ਹੈ। ਅਤੇ ਵਾਰਨ ਟੂਮੀ ਦਾ ਧੰਨਵਾਦ (ਜਿਸ ਨੇ TUHS ਪ੍ਰੋਜੈਕਟ ਸ਼ੁਰੂ ਕੀਤਾ) ਤੁਸੀਂ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦੇ ਹੋ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਲਈ ਸਰੋਤ ਕੋਡ ਵਾਲੀ PDF ਫਾਈਲ. ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਚਾਰ ਦੇਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਫਾਈਲ ਬਣਾਉਣ ਵਿੱਚ ਕਿੰਨੀ ਮਿਹਨਤ ਕੀਤੀ ਗਈ ਹੈ:

15 ਸਾਲ ਪਹਿਲਾਂ, ਮੈਂ ਦਿੱਤੇ ਗਏ ਸਰੋਤ ਕੋਡ ਦੀ ਇੱਕ ਕਾਪੀ ਟਾਈਪ ਕੀਤੀ ਸੀ ਲਾਇਨਜ਼, ਕਿਉਂਕਿ ਮੈਨੂੰ ਹੋਰ ਕਾਪੀਆਂ ਦੀ ਅਣਜਾਣ ਗਿਣਤੀ ਤੋਂ ਮੇਰੀ ਕਾਪੀ ਦੀ ਗੁਣਵੱਤਾ ਪਸੰਦ ਨਹੀਂ ਸੀ। TUHS ਅਜੇ ਮੌਜੂਦ ਨਹੀਂ ਸੀ ਅਤੇ ਮੇਰੇ ਕੋਲ ਪੁਰਾਣੇ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਸੀ। ਪਰ 1988 ਵਿੱਚ, ਮੈਨੂੰ ਇੱਕ ਪੁਰਾਣੀ 9-ਟਰੈਕ ਟੇਪ ਮਿਲੀ ਜਿਸ ਵਿੱਚ ਇੱਕ PDP11 ਕੰਪਿਊਟਰ ਤੋਂ ਬੈਕਅੱਪ ਸ਼ਾਮਲ ਸੀ। ਇਹ ਦੱਸਣਾ ਔਖਾ ਸੀ ਕਿ ਕੀ ਇਹ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਪਰ ਇੱਕ ਬਰਕਰਾਰ /usr/src/ ਟ੍ਰੀ ਸੀ ਜਿਸ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਫਾਈਲਾਂ ਨੂੰ ਸਾਲ 1979 ਦੇ ਨਾਲ ਲੇਬਲ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਕਿ ਉਦੋਂ ਵੀ ਪ੍ਰਾਚੀਨ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ। ਇਹ ਸੱਤਵਾਂ ਐਡੀਸ਼ਨ ਸੀ ਜਾਂ ਇਸਦਾ ਡੈਰੀਵੇਟਿਵ PWB, ਜਿਵੇਂ ਕਿ ਮੈਂ ਵਿਸ਼ਵਾਸ ਕੀਤਾ ਸੀ।

ਮੈਂ ਖੋਜ ਨੂੰ ਇੱਕ ਅਧਾਰ ਵਜੋਂ ਲਿਆ ਅਤੇ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਵਿੱਚ ਸਰੋਤਾਂ ਨੂੰ ਹੱਥੀਂ ਸੰਪਾਦਿਤ ਕੀਤਾ। ਕੁਝ ਕੋਡ ਇੱਕੋ ਜਿਹੇ ਰਹੇ, ਪਰ ਕੁਝ ਨੂੰ ਥੋੜ੍ਹਾ ਸੰਪਾਦਿਤ ਕਰਨਾ ਪਿਆ, ਆਧੁਨਿਕ += ਟੋਕਨ ਨੂੰ ਪੁਰਾਣੇ =+ ਵਿੱਚ ਬਦਲਣਾ। ਕੁਝ ਚੀਜ਼ਾਂ ਨੂੰ ਸਿਰਫ਼ ਮਿਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਕੁਝ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਿਆ, ਪਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਹੀਂ।

ਅਤੇ ਅੱਜ ਅਸੀਂ TUHS 'ਤੇ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਦਾ ਸਰੋਤ ਕੋਡ ਆਨਲਾਈਨ ਪੜ੍ਹ ਸਕਦੇ ਹਾਂ ਪੁਰਾਲੇਖ, ਜਿਸ ਵਿੱਚ ਡੈਨਿਸ ਰਿਚੀ ਦਾ ਹੱਥ ਸੀ.

ਤਰੀਕੇ ਨਾਲ, ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਕੇਰਨੀਘਨ ਅਤੇ ਰਿਚੀ ਦੀ ਮਿਆਦ ਤੋਂ ਪਹਿਲਾਂ ਸੀ-ਕੋਡ ਦੀ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਸੰਖੇਪਤਾ. ਇਹ ਅਕਸਰ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿ ਮੈਂ ਆਪਣੀ ਸਾਈਟ 'ਤੇ ਇੱਕ ਮੁਕਾਬਲਤਨ ਤੰਗ ਡਿਸਪਲੇ ਖੇਤਰ ਨੂੰ ਫਿੱਟ ਕਰਨ ਲਈ ਵਿਆਪਕ ਸੰਪਾਦਨ ਦੇ ਬਿਨਾਂ ਕੋਡ ਦੇ ਟੁਕੜੇ ਸ਼ਾਮਲ ਕਰਨ ਦੇ ਯੋਗ ਹਾਂ.

ਸ਼ੁਰੂ ਵਿੱਚ /usr/sys/ken/pipe.c ਇੱਥੇ ਇੱਕ ਵਿਆਖਿਆਤਮਕ ਟਿੱਪਣੀ ਹੈ (ਅਤੇ ਹਾਂ, ਹੋਰ ਵੀ ਹੈ /usr/sys/dmr):

/*
 * Max allowable buffering per pipe.
 * This is also the max size of the
 * file created to implement the pipe.
 * If this size is bigger than 4096,
 * pipes will be implemented in LARG
 * files, which is probably not good.
 */
#define    PIPSIZ    4096

ਚੌਥੇ ਐਡੀਸ਼ਨ ਤੋਂ ਬਾਅਦ ਬਫਰ ਦਾ ਆਕਾਰ ਨਹੀਂ ਬਦਲਿਆ ਹੈ। ਪਰ ਇੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ, ਬਿਨਾਂ ਕਿਸੇ ਜਨਤਕ ਦਸਤਾਵੇਜ਼ ਦੇ, ਪਾਈਪਲਾਈਨਾਂ ਨੇ ਇੱਕ ਵਾਰ ਬੈਕਅਪ ਸਟੋਰੇਜ ਵਜੋਂ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ!

ਜਿਵੇਂ ਕਿ LARG ਫਾਈਲਾਂ ਲਈ, ਉਹ ਇਸਦੇ ਅਨੁਸਾਰੀ ਹਨ inode ਫਲੈਗ LARG, ਜਿਸਦੀ ਵਰਤੋਂ ਪ੍ਰਕਿਰਿਆ ਲਈ "ਵੱਡੇ ਐਡਰੈਸਿੰਗ ਐਲਗੋਰਿਦਮ" ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਸਿੱਧੇ ਬਲਾਕ ਵੱਡੇ ਫਾਈਲ ਸਿਸਟਮਾਂ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ. ਕਿਉਂਕਿ ਕੇਨ ਨੇ ਕਿਹਾ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ, ਮੈਂ ਖੁਸ਼ੀ ਨਾਲ ਉਸਦੇ ਸ਼ਬਦ ਨੂੰ ਮੰਨਾਂਗਾ।

ਇੱਥੇ ਅਸਲੀ ਸਿਸਟਮ ਕਾਲ ਹੈ pipe:

/*
 * The sys-pipe entry.
 * Allocate an inode on the root device.
 * Allocate 2 file structures.
 * Put it all together with flags.
 */
pipe()
{
    register *ip, *rf, *wf;
    int r;

    ip = ialloc(rootdev);
    if(ip == NULL)
        return;
    rf = falloc();
    if(rf == NULL) {
        iput(ip);
        return;
    }
    r = u.u_ar0[R0];
    wf = falloc();
    if(wf == NULL) {
        rf->f_count = 0;
        u.u_ofile[r] = NULL;
        iput(ip);
        return;
    }
    u.u_ar0[R1] = u.u_ar0[R0]; /* wf's fd */
    u.u_ar0[R0] = r;           /* rf's fd */
    wf->f_flag = FWRITE|FPIPE;
    wf->f_inode = ip;
    rf->f_flag = FREAD|FPIPE;
    rf->f_inode = ip;
    ip->i_count = 2;
    ip->i_flag = IACC|IUPD;
    ip->i_mode = IALLOC;
}

ਟਿੱਪਣੀ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਪਰ ਕੋਡ ਨੂੰ ਸਮਝਣਾ ਇੰਨਾ ਆਸਾਨ ਨਹੀਂ ਹੈ, ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਤਰੀਕੇ ਨਾਲ "struct ਯੂਜ਼ਰ ਯੂ» ਅਤੇ ਰਜਿਸਟਰ R0 и R1 ਸਿਸਟਮ ਕਾਲ ਪੈਰਾਮੀਟਰ ਅਤੇ ਵਾਪਸੀ ਮੁੱਲ ਪਾਸ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਦੇ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ialloc() ਡਿਸਕ 'ਤੇ ਪਾਓ ਆਈਨੋਡ (ਇੰਡੈਕਸ ਹੈਂਡਲ), ਅਤੇ ਮਦਦ ਨਾਲ falloc() - ਮੈਮੋਰੀ ਵਿੱਚ ਦੋ ਰੱਖੋ ਫਾਈਲ. ਜੇਕਰ ਸਭ ਕੁਝ ਠੀਕ ਰਿਹਾ, ਤਾਂ ਅਸੀਂ ਇਹਨਾਂ ਫਾਈਲਾਂ ਨੂੰ ਪਾਈਪਲਾਈਨ ਦੇ ਦੋ ਸਿਰਿਆਂ ਵਜੋਂ ਪਛਾਣਨ ਲਈ ਫਲੈਗ ਸੈਟ ਕਰਾਂਗੇ, ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਆਈਨੋਡ (ਜਿਸ ਦੀ ਸੰਦਰਭ ਗਿਣਤੀ 2 'ਤੇ ਸੈੱਟ ਕੀਤੀ ਜਾਵੇਗੀ) ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਾਂਗੇ, ਅਤੇ ਆਈਨੋਡ ਨੂੰ ਸੋਧੇ ਹੋਏ ਅਤੇ ਵਰਤੋਂ ਵਿੱਚ ਮਾਰਕ ਕਰੋਗੇ। ਦੀਆਂ ਬੇਨਤੀਆਂ ਵੱਲ ਧਿਆਨ ਦਿਓ ਮੈਂ ਪਾਇਆ() ਨਵੇਂ ਆਈਨੋਡ ਵਿੱਚ ਸੰਦਰਭ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਣ ਲਈ ਗਲਤੀ ਮਾਰਗਾਂ ਵਿੱਚ।

pipe() ਦੁਆਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ R0 и R1 ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਲਈ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਨੰਬਰ ਵਾਪਸ ਕਰੋ। falloc() ਫਾਈਲ ਢਾਂਚੇ ਲਈ ਇੱਕ ਪੁਆਇੰਟਰ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਪਰ ਰਾਹੀਂ "ਵਾਪਸੀ" ਵੀ ਕਰਦਾ ਹੈ u.u_ar0[R0] ਅਤੇ ਇੱਕ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ। ਭਾਵ, ਕੋਡ ਵਿੱਚ ਬਚਦਾ ਹੈ r ਪੜ੍ਹਨ ਲਈ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਅਤੇ ਸਿੱਧੇ ਤੋਂ ਲਿਖਣ ਲਈ ਇੱਕ ਫਾਈਲ ਡਿਸਕ੍ਰਿਪਟਰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ u.u_ar0[R0] ਦੂਜੀ ਕਾਲ ਦੇ ਬਾਅਦ falloc().

ਫਲੈਗ FPIPE, ਜੋ ਅਸੀਂ ਪਾਈਪਲਾਈਨ ਬਣਾਉਣ ਵੇਲੇ ਸੈਟ ਕਰਦੇ ਹਾਂ, ਫੰਕਸ਼ਨ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ rdwr() sys2.c ਵਿੱਚਖਾਸ I/O ਰੁਟੀਨਾਂ ਨੂੰ ਕਾਲ ਕਰਨਾ:

/*
 * common code for read and write calls:
 * check permissions, set base, count, and offset,
 * and switch out to readi, writei, or pipe code.
 */
rdwr(mode)
{
    register *fp, m;

    m = mode;
    fp = getf(u.u_ar0[R0]);
        /* … */

    if(fp->f_flag&FPIPE) {
        if(m==FREAD)
            readp(fp); else
            writep(fp);
    }
        /* … */
}

ਫਿਰ ਫੰਕਸ਼ਨ readp() в pipe.c ਪਾਈਪਲਾਈਨ ਤੋਂ ਡਾਟਾ ਪੜ੍ਹਦਾ ਹੈ। ਪਰ ਇਸ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਲਾਗੂ ਕਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਬਿਹਤਰ ਹੈ writep(). ਦੁਬਾਰਾ, ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੇ ਸੰਮੇਲਨਾਂ ਕਾਰਨ ਕੋਡ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਬਣ ਗਿਆ ਹੈ, ਪਰ ਕੁਝ ਵੇਰਵਿਆਂ ਨੂੰ ਛੱਡਿਆ ਜਾ ਸਕਦਾ ਹੈ।

writep(fp)
{
    register *rp, *ip, c;

    rp = fp;
    ip = rp->f_inode;
    c = u.u_count;

loop:
    /* If all done, return. */

    plock(ip);
    if(c == 0) {
        prele(ip);
        u.u_count = 0;
        return;
    }

    /*
     * If there are not both read and write sides of the
     * pipe active, return error and signal too.
     */

    if(ip->i_count < 2) {
        prele(ip);
        u.u_error = EPIPE;
        psignal(u.u_procp, SIGPIPE);
        return;
    }

    /*
     * If the pipe is full, wait for reads to deplete
     * and truncate it.
     */

    if(ip->i_size1 == PIPSIZ) {
        ip->i_mode =| IWRITE;
        prele(ip);
        sleep(ip+1, PPIPE);
        goto loop;
    }

    /* Write what is possible and loop back. */

    u.u_offset[0] = 0;
    u.u_offset[1] = ip->i_size1;
    u.u_count = min(c, PIPSIZ-u.u_offset[1]);
    c =- u.u_count;
    writei(ip);
    prele(ip);
    if(ip->i_mode&IREAD) {
        ip->i_mode =& ~IREAD;
        wakeup(ip+2);
    }
    goto loop;
}

ਅਸੀਂ ਪਾਈਪਲਾਈਨ ਇਨਪੁਟ 'ਤੇ ਬਾਈਟਸ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ u.u_count. ਪਹਿਲਾਂ ਸਾਨੂੰ ਇਨੋਡ ਨੂੰ ਲਾਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਹੇਠਾਂ ਦੇਖੋ plock/prele).

ਫਿਰ ਅਸੀਂ ਇਨੋਡ ਰੈਫਰੈਂਸ ਕਾਊਂਟਰ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ। ਜਿੰਨਾ ਚਿਰ ਪਾਈਪਲਾਈਨ ਦੇ ਦੋਵੇਂ ਸਿਰੇ ਖੁੱਲ੍ਹੇ ਰਹਿੰਦੇ ਹਨ, ਕਾਊਂਟਰ 2 ਦੇ ਬਰਾਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਸੀਂ ਇੱਕ ਲਿੰਕ ਰੱਖਦੇ ਹਾਂ (ਤੋਂ rp->f_inode), ਇਸ ਲਈ ਜੇਕਰ ਕਾਊਂਟਰ 2 ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਰੀਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੇ ਪਾਈਪਲਾਈਨ ਦੇ ਆਪਣੇ ਅੰਤ ਨੂੰ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਅਸੀਂ ਇੱਕ ਬੰਦ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਅਤੇ ਇਹ ਇੱਕ ਗਲਤੀ ਹੈ। ਪਹਿਲੀ ਵਾਰ ਗਲਤੀ ਕੋਡ EPIPE ਅਤੇ ਸਿਗਨਲ SIGPIPE ਯੂਨਿਕਸ ਦੇ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ।

ਪਰ ਭਾਵੇਂ ਕਨਵੇਅਰ ਖੁੱਲ੍ਹਾ ਹੈ, ਇਹ ਭਰਿਆ ਹੋ ਸਕਦਾ ਹੈ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਲਾਕ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਇਸ ਉਮੀਦ ਵਿੱਚ ਸੌਂ ਜਾਂਦੇ ਹਾਂ ਕਿ ਇੱਕ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹੇਗੀ ਅਤੇ ਇਸ ਵਿੱਚ ਕਾਫ਼ੀ ਜਗ੍ਹਾ ਖਾਲੀ ਕਰ ਦੇਵੇਗੀ। ਜਾਗਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸ਼ੁਰੂਆਤ 'ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ, ਲਾਕ ਨੂੰ ਦੁਬਾਰਾ ਲਟਕਾਉਂਦੇ ਹਾਂ ਅਤੇ ਇੱਕ ਨਵਾਂ ਰਿਕਾਰਡਿੰਗ ਚੱਕਰ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ।

ਜੇਕਰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕਾਫ਼ੀ ਖਾਲੀ ਥਾਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੇਟਾ ਲਿਖਦੇ ਹਾਂ ਲਿਖੋ (). ਪੈਰਾਮੀਟਰ i_size1 inode (ਜੇ ਪਾਈਪਲਾਈਨ ਖਾਲੀ ਹੈ ਤਾਂ ਇਹ 0 ਦੇ ਬਰਾਬਰ ਹੋ ਸਕਦੀ ਹੈ) ਉਸ ਡੇਟਾ ਦੇ ਅੰਤ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜੋ ਇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ। ਜੇ ਉੱਥੇ ਕਾਫ਼ੀ ਰਿਕਾਰਡਿੰਗ ਸਪੇਸ ਹੈ, ਤਾਂ ਅਸੀਂ ਪਾਈਪਲਾਈਨ ਨੂੰ ਭਰ ਸਕਦੇ ਹਾਂ i_size1 ਨੂੰ PIPESIZ. ਫਿਰ ਅਸੀਂ ਲਾਕ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਾਂ ਅਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਜਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਜੋ ਪਾਈਪਲਾਈਨ ਤੋਂ ਪੜ੍ਹਨ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ. ਅਸੀਂ ਇਹ ਦੇਖਣ ਲਈ ਸ਼ੁਰੂ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦੇ ਹਾਂ ਕਿ ਕੀ ਅਸੀਂ ਲੋੜੀਂਦੇ ਬਾਈਟਾਂ ਨੂੰ ਲਿਖਣ ਦੇ ਯੋਗ ਸੀ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਰਿਕਾਰਡਿੰਗ ਚੱਕਰ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ।

ਆਮ ਤੌਰ 'ਤੇ ਪੈਰਾਮੀਟਰ i_mode inode ਦੀ ਵਰਤੋਂ ਇਜਾਜ਼ਤਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ r, w и x. ਪਰ ਪਾਈਪਲਾਈਨਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਸੀਂ ਸੰਕੇਤ ਦਿੰਦੇ ਹਾਂ ਕਿ ਕੁਝ ਪ੍ਰਕਿਰਿਆ ਬਿੱਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖਣ ਜਾਂ ਪੜ੍ਹਨ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ IREAD и IWRITE ਕ੍ਰਮਵਾਰ. ਪ੍ਰਕਿਰਿਆ ਫਲੈਗ ਅਤੇ ਕਾਲਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦੀ ਹੈ sleep(), ਅਤੇ ਇਹ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਭਵਿੱਖ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਦਾ ਕਾਰਨ ਬਣੇਗਾ wakeup().

ਅਸਲੀ ਜਾਦੂ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ sleep() и wakeup(). ਵਿੱਚ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ slp.c, ਮਸ਼ਹੂਰ "ਤੁਹਾਡੇ ਤੋਂ ਇਹ ਸਮਝਣ ਦੀ ਉਮੀਦ ਨਹੀਂ ਹੈ" ਟਿੱਪਣੀ ਦਾ ਸਰੋਤ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਾਨੂੰ ਕੋਡ ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਬੱਸ ਕੁਝ ਟਿੱਪਣੀਆਂ ਦੇਖੋ:

/*
 * Give up the processor till a wakeup occurs
 * on chan, at which time the process
 * enters the scheduling queue at priority pri.
 * The most important effect of pri is that when
 * pri<0 a signal cannot disturb the sleep;
 * if pri>=0 signals will be processed.
 * Callers of this routine must be prepared for
 * premature return, and check that the reason for
 * sleeping has gone away.
 */
sleep(chan, pri) /* … */

/*
 * Wake up all processes sleeping on chan.
 */
wakeup(chan) /* … */

ਪ੍ਰਕਿਰਿਆ ਜੋ ਕਾਰਨ ਬਣਦੀ ਹੈ sleep() ਇੱਕ ਖਾਸ ਚੈਨਲ ਲਈ, ਬਾਅਦ ਵਿੱਚ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਜਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸਦਾ ਕਾਰਨ ਹੋਵੇਗਾ wakeup() ਉਸੇ ਚੈਨਲ ਲਈ। writep() и readp() ਅਜਿਹੀਆਂ ਪੇਅਰਡ ਕਾਲਾਂ ਰਾਹੀਂ ਉਹਨਾਂ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦਾ ਤਾਲਮੇਲ ਕਰੋ। ਨੋਟ ਕਰੋ pipe.c ਹਮੇਸ਼ਾ ਪਹਿਲ ਦਿੰਦਾ ਹੈ PPIPE ਜਦੋਂ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ sleep(), ਇਸ ਲਈ ਇਹ ਹੈ sleep() ਇੱਕ ਸਿਗਨਲ ਦੁਆਰਾ ਰੁਕਾਵਟ ਹੋ ਸਕਦੀ ਹੈ।

ਹੁਣ ਸਾਡੇ ਕੋਲ ਫੰਕਸ਼ਨ ਨੂੰ ਸਮਝਣ ਲਈ ਸਭ ਕੁਝ ਹੈ readp():

readp(fp)
int *fp;
{
    register *rp, *ip;

    rp = fp;
    ip = rp->f_inode;

loop:
    /* Very conservative locking. */

    plock(ip);

    /*
     * If the head (read) has caught up with
     * the tail (write), reset both to 0.
     */

    if(rp->f_offset[1] == ip->i_size1) {
        if(rp->f_offset[1] != 0) {
            rp->f_offset[1] = 0;
            ip->i_size1 = 0;
            if(ip->i_mode&IWRITE) {
                ip->i_mode =& ~IWRITE;
                wakeup(ip+1);
            }
        }

        /*
         * If there are not both reader and
         * writer active, return without
         * satisfying read.
         */

        prele(ip);
        if(ip->i_count < 2)
            return;
        ip->i_mode =| IREAD;
        sleep(ip+2, PPIPE);
        goto loop;
    }

    /* Read and return */

    u.u_offset[0] = 0;
    u.u_offset[1] = rp->f_offset[1];
    readi(ip);
    rp->f_offset[1] = u.u_offset[1];
    prele(ip);
}

ਤੁਹਾਨੂੰ ਇਸ ਫੰਕਸ਼ਨ ਨੂੰ ਹੇਠਾਂ ਤੋਂ ਉੱਪਰ ਤੱਕ ਪੜ੍ਹਨਾ ਆਸਾਨ ਲੱਗ ਸਕਦਾ ਹੈ। "ਪੜ੍ਹੋ ਅਤੇ ਵਾਪਸ" ਸ਼ਾਖਾ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਕੁਝ ਡੇਟਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ Readi() ਅਸੀਂ ਮੌਜੂਦਾ ਡੇਟਾ ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ ਉਪਲਬਧ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਦੇ ਹਾਂ f_offset ਪੜ੍ਹੋ, ਅਤੇ ਫਿਰ ਸੰਬੰਧਿਤ ਆਫਸੈੱਟ ਦੇ ਮੁੱਲ ਨੂੰ ਅਪਡੇਟ ਕਰੋ।

ਬਾਅਦ ਦੇ ਰੀਡਜ਼ 'ਤੇ, ਪਾਈਪਲਾਈਨ ਖਾਲੀ ਹੋ ਜਾਵੇਗੀ ਜੇਕਰ ਰੀਡ ਆਫਸੈੱਟ ਪਹੁੰਚ ਗਿਆ ਹੈ i_size1 inode 'ਤੇ. ਅਸੀਂ ਸਥਿਤੀ ਨੂੰ 0 ਤੇ ਰੀਸੈਟ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਜਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਜੋ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲਿਖਣਾ ਚਾਹੁੰਦਾ ਹੈ. ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਜਦੋਂ ਕਨਵੇਅਰ ਭਰ ਜਾਂਦਾ ਹੈ, writep() 'ਤੇ ਸੌਂ ਜਾਵੇਗਾ ip+1. ਅਤੇ ਹੁਣ ਜਦੋਂ ਪਾਈਪਲਾਈਨ ਖਾਲੀ ਹੈ, ਅਸੀਂ ਇਸਨੂੰ ਲਿਖਣ ਦੇ ਚੱਕਰ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਜਗਾ ਸਕਦੇ ਹਾਂ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪੜ੍ਹਨ ਲਈ ਕੁਝ ਨਹੀਂ ਹੈ, ਤਾਂ readp() ਝੰਡਾ ਸੈੱਟ ਕਰ ਸਕਦਾ ਹੈ IREAD ਅਤੇ ਸੌਂ ਜਾਓ ip+2. ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਉਸ ਨੂੰ ਕੀ ਜਗਾਏਗਾ writep(), ਜਦੋਂ ਇਹ ਪਾਈਪਲਾਈਨ ਨੂੰ ਕੁਝ ਡੇਟਾ ਲਿਖਦਾ ਹੈ।

ਲਈ ਟਿੱਪਣੀਆਂ readi() ਅਤੇ writei() ਇਹ ਸਮਝਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ ਕਿ ਮਾਪਦੰਡਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦੀ ਬਜਾਏ "u"ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਮ I/O ਫੰਕਸ਼ਨਾਂ ਵਾਂਗ ਵਰਤ ਸਕਦੇ ਹਾਂ ਜੋ ਇੱਕ ਫਾਈਲ, ਇੱਕ ਸਥਿਤੀ, ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਬਫਰ ਲੈਂਦੇ ਹਨ, ਅਤੇ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਲਈ ਬਾਈਟਾਂ ਦੀ ਗਿਣਤੀ ਕਰਦੇ ਹਨ।

/*
 * Read the file corresponding to
 * the inode pointed at by the argument.
 * The actual read arguments are found
 * in the variables:
 *    u_base        core address for destination
 *    u_offset    byte offset in file
 *    u_count        number of bytes to read
 *    u_segflg    read to kernel/user
 */
readi(aip)
struct inode *aip;
/* … */

/*
 * Write the file corresponding to
 * the inode pointed at by the argument.
 * The actual write arguments are found
 * in the variables:
 *    u_base        core address for source
 *    u_offset    byte offset in file
 *    u_count        number of bytes to write
 *    u_segflg    write to kernel/user
 */
writei(aip)
struct inode *aip;
/* … */

ਜਿਵੇਂ ਕਿ "ਰੂੜੀਵਾਦੀ" ਬਲਾਕਿੰਗ ਲਈ, ਫਿਰ readp() и writep() ਆਈਨੋਡ ਨੂੰ ਉਦੋਂ ਤੱਕ ਬਲੌਕ ਕਰੋ ਜਦੋਂ ਤੱਕ ਉਹ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਨਹੀਂ ਕਰ ਲੈਂਦੇ ਜਾਂ ਨਤੀਜਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦੇ (ਭਾਵ, ਕਾਲ ਕਰੋ wakeup). plock() и prele() ਬਸ ਕੰਮ ਕਰੋ: ਕਾਲਾਂ ਦਾ ਇੱਕ ਵੱਖਰਾ ਸੈੱਟ ਵਰਤ ਕੇ sleep и wakeup ਸਾਨੂੰ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਜਗਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜਿਸ ਲਈ ਲਾਕ ਦੀ ਲੋੜ ਹੈ ਜੋ ਅਸੀਂ ਹੁਣੇ ਜਾਰੀ ਕੀਤਾ ਹੈ:

/*
 * Lock a pipe.
 * If its already locked, set the WANT bit and sleep.
 */
plock(ip)
int *ip;
{
    register *rp;

    rp = ip;
    while(rp->i_flag&ILOCK) {
        rp->i_flag =| IWANT;
        sleep(rp, PPIPE);
    }
    rp->i_flag =| ILOCK;
}

/*
 * Unlock a pipe.
 * If WANT bit is on, wakeup.
 * This routine is also used to unlock inodes in general.
 */
prele(ip)
int *ip;
{
    register *rp;

    rp = ip;
    rp->i_flag =& ~ILOCK;
    if(rp->i_flag&IWANT) {
        rp->i_flag =& ~IWANT;
        wakeup(rp);
    }
}

ਪਹਿਲਾਂ ਤਾਂ ਮੈਂ ਸਮਝ ਨਹੀਂ ਸਕਿਆ ਕਿ ਕਿਉਂ readp() ਦਾ ਕਾਰਨ ਨਹੀ ਹੈ prele(ip) ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ wakeup(ip+1). ਪਹਿਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ writep() ਇਸ ਦੇ ਚੱਕਰ ਵਿੱਚ ਕਾਰਨ, ਇਹ plock(ip), ਜੋ ਡੈੱਡਲਾਕ ਦੀ ਅਗਵਾਈ ਕਰਦਾ ਹੈ if readp() ਅਜੇ ਤੱਕ ਮੇਰੇ ਬਲਾਕ ਨੂੰ ਨਹੀਂ ਹਟਾਇਆ ਹੈ, ਇਸ ਲਈ ਕਿਸੇ ਤਰ੍ਹਾਂ ਕੋਡ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਜੇ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ wakeup(), ਫਿਰ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਸਿਰਫ ਸਲੀਪਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਭਵਿੱਖ ਵਿੱਚ sched() ਅਸਲ ਵਿੱਚ ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਕੀਤਾ. ਇਸ ਲਈ readp() ਕਾਰਨ wakeup(), ਲਾਕ ਨੂੰ ਹਟਾਉਂਦਾ ਹੈ, ਸੈੱਟ ਕਰਦਾ ਹੈ IREAD ਅਤੇ ਕਾਲਾਂ sleep(ip+2)- ਇਹ ਸਭ ਪਹਿਲਾਂ writep() ਚੱਕਰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਇਹ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਵਿੱਚ ਕਨਵੇਅਰਾਂ ਦੇ ਵਰਣਨ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ। ਸਧਾਰਨ ਕੋਡ, ਦੂਰਗਾਮੀ ਨਤੀਜੇ।

ਯੂਨਿਕਸ ਦਾ ਸੱਤਵਾਂ ਐਡੀਸ਼ਨ (ਜਨਵਰੀ 1979) ਇੱਕ ਨਵਾਂ ਪ੍ਰਮੁੱਖ ਰੀਲੀਜ਼ ਸੀ (ਚਾਰ ਸਾਲ ਬਾਅਦ) ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਨਵੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਕਰਨਲ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪੇਸ਼ ਕੀਤੀਆਂ ਗਈਆਂ। ਇਸ ਵਿੱਚ ਟਾਈਪ ਕਾਸਟਿੰਗ, ਯੂਨੀਅਨਾਂ ਅਤੇ ਟਾਈਪ ਕੀਤੇ ਪੁਆਇੰਟਰਾਂ ਨੂੰ ਬਣਤਰਾਂ ਦੀ ਵਰਤੋਂ ਦੇ ਸਬੰਧ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਤਬਦੀਲੀਆਂ ਵੀ ਆਈਆਂ। ਹਾਲਾਂਕਿ ਕਨਵੇਅਰ ਕੋਡ ਅਮਲੀ ਤੌਰ 'ਤੇ ਬਦਲਿਆ ਨਹੀਂ। ਅਸੀਂ ਇਸ ਸੰਸਕਰਨ ਨੂੰ ਛੱਡ ਸਕਦੇ ਹਾਂ।

Xv6, ਇੱਕ ਸਧਾਰਨ ਯੂਨਿਕਸ ਵਰਗਾ ਕਰਨਲ

ਕਰਨਲ ਬਣਾਉਣ ਲਈ Xv6 ਯੂਨਿਕਸ ਦੇ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਤੋਂ ਪ੍ਰਭਾਵਿਤ ਹੈ, ਪਰ ਇਹ x86 ਪ੍ਰੋਸੈਸਰਾਂ 'ਤੇ ਚੱਲਣ ਲਈ ਆਧੁਨਿਕ C ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਕੋਡ ਪੜ੍ਹਨ ਅਤੇ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਹੈ। ਨਾਲ ਹੀ, TUHS ਨਾਲ ਯੂਨਿਕਸ ਸਰੋਤਾਂ ਦੇ ਉਲਟ, ਤੁਸੀਂ ਇਸਨੂੰ ਕੰਪਾਇਲ ਕਰ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਸੋਧ ਸਕਦੇ ਹੋ, ਅਤੇ ਇਸਨੂੰ PDP 11/70 ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ 'ਤੇ ਚਲਾ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ, ਇਹ ਕਰਨਲ ਯੂਨੀਵਰਸਿਟੀਆਂ ਵਿੱਚ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ 'ਤੇ ਵਿਦਿਅਕ ਸਮੱਗਰੀ ਵਜੋਂ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਸਰੋਤ Github 'ਤੇ ਹਨ.

ਕੋਡ ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ ਅਤੇ ਵਿਚਾਰਸ਼ੀਲ ਲਾਗੂਕਰਨ ਸ਼ਾਮਲ ਹੈ ਪਾਈਪ.ਸੀ, ਡਿਸਕ ਉੱਤੇ ਇੱਕ inode ਦੀ ਬਜਾਏ ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਬਫਰ ਦੁਆਰਾ ਸਮਰਥਿਤ ਹੈ। ਇੱਥੇ ਮੈਂ ਸਿਰਫ "ਢਾਂਚਾਗਤ ਪਾਈਪਲਾਈਨ" ਅਤੇ ਫੰਕਸ਼ਨ ਦੀ ਪਰਿਭਾਸ਼ਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹਾਂ pipealloc():

#define PIPESIZE 512

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

int
pipealloc(struct file **f0, struct file **f1)
{
  struct pipe *p;

  p = 0;
  *f0 = *f1 = 0;
  if((*f0 = filealloc()) == 0 || (*f1 = filealloc()) == 0)
    goto bad;
  if((p = (struct pipe*)kalloc()) == 0)
    goto bad;
  p->readopen = 1;
  p->writeopen = 1;
  p->nwrite = 0;
  p->nread = 0;
  initlock(&p->lock, "pipe");
  (*f0)->type = FD_PIPE;
  (*f0)->readable = 1;
  (*f0)->writable = 0;
  (*f0)->pipe = p;
  (*f1)->type = FD_PIPE;
  (*f1)->readable = 0;
  (*f1)->writable = 1;
  (*f1)->pipe = p;
  return 0;

 bad:
  if(p)
    kfree((char*)p);
  if(*f0)
    fileclose(*f0);
  if(*f1)
    fileclose(*f1);
  return -1;
}

pipealloc() ਬਾਕੀ ਲਾਗੂ ਕਰਨ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਫੰਕਸ਼ਨ ਸ਼ਾਮਲ ਹਨ piperead(), pipewrite() и pipeclose(). ਅਸਲ ਸਿਸਟਮ ਕਾਲ sys_pipe ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਇੱਕ ਰੈਪਰ ਹੈ sysfile.c. ਮੈਂ ਉਸਦਾ ਪੂਰਾ ਕੋਡ ਪੜ੍ਹਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ. ਜਟਿਲਤਾ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਦੇ ਸਰੋਤ ਕੋਡ ਦੇ ਪੱਧਰ 'ਤੇ ਹੈ, ਪਰ ਇਹ ਪੜ੍ਹਨਾ ਬਹੁਤ ਸੌਖਾ ਅਤੇ ਵਧੇਰੇ ਮਜ਼ੇਦਾਰ ਹੈ।

ਲੀਨਿਕਸ 0.01

ਲੀਨਕਸ 0.01 ਸਰੋਤ ਕੋਡ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਉਸ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਸਿੱਖਿਆਦਾਇਕ ਹੋਵੇਗਾ fs/pipe.c. ਇਹ ਪਾਈਪਲਾਈਨ ਨੂੰ ਦਰਸਾਉਣ ਲਈ ਇੱਕ ਆਈਨੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਪਰ ਪਾਈਪਲਾਈਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਆਧੁਨਿਕ C ਵਿੱਚ ਲਿਖੀ ਗਈ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ 6ਵੇਂ ਐਡੀਸ਼ਨ ਕੋਡ ਰਾਹੀਂ ਆਪਣੇ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕੀਤਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਥੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋਵੇਗੀ। ਇਹ ਫੰਕਸ਼ਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ write_pipe():

int write_pipe(struct m_inode * inode, char * buf, int count)
{
    char * b=buf;

    wake_up(&inode->i_wait);
    if (inode->i_count != 2) { /* no readers */
        current->signal |= (1<<(SIGPIPE-1));
        return -1;
    }
    while (count-->0) {
        while (PIPE_FULL(*inode)) {
            wake_up(&inode->i_wait);
            if (inode->i_count != 2) {
                current->signal |= (1<<(SIGPIPE-1));
                return b-buf;
            }
            sleep_on(&inode->i_wait);
        }
        ((char *)inode->i_size)[PIPE_HEAD(*inode)] =
            get_fs_byte(b++);
        INC_PIPE( PIPE_HEAD(*inode) );
        wake_up(&inode->i_wait);
    }
    wake_up(&inode->i_wait);
    return b-buf;
}

ਸੰਰਚਨਾ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਵੇਖੇ ਬਿਨਾਂ, ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ ਕਿ ਕਿਵੇਂ ਆਈਨੋਡ ਸੰਦਰਭ ਗਿਣਤੀ ਦੀ ਵਰਤੋਂ ਇਹ ਦੇਖਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਕੀ ਇੱਕ ਰਾਈਟ ਓਪਰੇਸ਼ਨ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ SIGPIPE. ਬਾਈਟ-ਬਾਈ-ਬਾਈਟ ਕੰਮ ਕਰਨ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਫੰਕਸ਼ਨ ਉੱਪਰ ਦੱਸੇ ਗਏ ਵਿਚਾਰਾਂ ਨਾਲ ਤੁਲਨਾ ਕਰਨਾ ਆਸਾਨ ਹੈ. ਇੱਥੋਂ ਤੱਕ ਕਿ ਤਰਕ ਵੀ sleep_on/wake_up ਇੰਨਾ ਪਰਦੇਸੀ ਨਹੀਂ ਲੱਗਦਾ।

ਆਧੁਨਿਕ ਲੀਨਕਸ ਕਰਨਲ, ਫ੍ਰੀਬੀਐਸਡੀ, ਨੈੱਟਬੀਐਸਡੀ, ਓਪਨਬੀਐਸਡੀ

ਮੈਂ ਤੇਜ਼ੀ ਨਾਲ ਕੁਝ ਆਧੁਨਿਕ ਕਰਨਲਾਂ ਵਿੱਚੋਂ ਲੰਘਿਆ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਕੋਲ ਵੀ ਹੁਣ ਡਿਸਕ ਲਾਗੂ ਨਹੀਂ ਹੈ (ਹੈਰਾਨੀ ਵਾਲੀ ਗੱਲ ਨਹੀਂ)। ਲੀਨਕਸ ਦਾ ਆਪਣਾ ਲਾਗੂਕਰਨ ਹੈ। ਹਾਲਾਂਕਿ ਤਿੰਨ ਆਧੁਨਿਕ BSD ਕਰਨਲਾਂ ਵਿੱਚ ਕੋਡ ਦੇ ਅਧਾਰ ਤੇ ਲਾਗੂਕਰਨ ਸ਼ਾਮਲ ਹਨ ਜੋ ਜੌਨ ਡਾਇਸਨ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਸਨ, ਸਾਲਾਂ ਵਿੱਚ ਉਹ ਇੱਕ ਦੂਜੇ ਤੋਂ ਬਹੁਤ ਵੱਖਰੇ ਹੋ ਗਏ ਹਨ।

ਪੜ੍ਹਨ ਲਈ fs/pipe.c (ਲੀਨਕਸ ਉੱਤੇ) ਜਾਂ sys/kern/sys_pipe.c (*BSD ਉੱਤੇ), ਇਸ ਨੂੰ ਅਸਲ ਸਮਰਪਣ ਦੀ ਲੋੜ ਹੈ। ਅੱਜ ਦਾ ਕੋਡ ਵੈਕਟਰ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ I/O ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਲਈ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਸਮਰਥਨ ਬਾਰੇ ਹੈ। ਅਤੇ ਮੈਮੋਰੀ ਵੰਡ, ਤਾਲੇ ਅਤੇ ਕਰਨਲ ਸੰਰਚਨਾ ਦੇ ਵੇਰਵੇ ਬਹੁਤ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ। ਇਹ ਉਹ ਨਹੀਂ ਹੈ ਜੋ ਕਾਲਜਾਂ ਨੂੰ ਇੱਕ ਸ਼ੁਰੂਆਤੀ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਕੋਰਸ ਲਈ ਲੋੜੀਂਦਾ ਹੈ।

ਵੈਸੇ ਵੀ, ਮੈਂ ਕੁਝ ਪੁਰਾਣੇ ਪੈਟਰਨਾਂ ਨੂੰ ਖੋਦਣ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਸੀ (ਜਿਵੇਂ ਕਿ ਪੈਦਾ ਕਰਨਾ SIGPIPE ਅਤੇ ਵਾਪਸੀ EPIPE ਇੱਕ ਬੰਦ ਪਾਈਪਲਾਈਨ ਨੂੰ ਲਿਖਣ ਵੇਲੇ) ਇਹਨਾਂ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਆਧੁਨਿਕ ਕਰਨਲਾਂ ਵਿੱਚ। ਮੈਂ ਸ਼ਾਇਦ ਅਸਲ ਜੀਵਨ ਵਿੱਚ ਕਦੇ ਵੀ PDP-11 ਕੰਪਿਊਟਰ ਨਹੀਂ ਦੇਖਾਂਗਾ, ਪਰ ਮੇਰੇ ਜਨਮ ਤੋਂ ਕਈ ਸਾਲ ਪਹਿਲਾਂ ਲਿਖੇ ਗਏ ਕੋਡ ਤੋਂ ਸਿੱਖਣ ਲਈ ਅਜੇ ਵੀ ਬਹੁਤ ਕੁਝ ਹੈ।

ਦਿਵੀ ਕਪੂਰ ਦੁਆਰਾ 2011 ਵਿੱਚ ਲਿਖਿਆ ਇੱਕ ਲੇਖ:ਪਾਈਪਾਂ ਅਤੇ FIFOs ਦਾ ਲੀਨਕਸ ਕਰਨਲ ਲਾਗੂ ਕਰਨਾ" ਲੀਨਕਸ ਵਿੱਚ ਪਾਈਪਲਾਈਨਾਂ (ਅਜੇ ਵੀ) ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ ਬਾਰੇ ਇੱਕ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਏ ਲੀਨਕਸ ਵਿੱਚ ਤਾਜ਼ਾ ਪ੍ਰਤੀਬੱਧਤਾ ਪਰਸਪਰ ਕ੍ਰਿਆ ਦੇ ਇੱਕ ਪਾਈਪਲਾਈਨ ਮਾਡਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਿਸਦੀ ਸਮਰੱਥਾ ਅਸਥਾਈ ਫਾਈਲਾਂ ਤੋਂ ਵੱਧ ਹੈ; ਅਤੇ ਇਹ ਵੀ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਛੇਵੇਂ ਐਡੀਸ਼ਨ ਯੂਨਿਕਸ ਕਰਨਲ ਦੇ "ਬਹੁਤ ਰੂੜੀਵਾਦੀ ਲਾਕਿੰਗ" ਤੋਂ ਪਾਈਪਲਾਈਨਾਂ ਕਿੰਨੀ ਦੂਰ ਆਈਆਂ ਹਨ।

ਸਰੋਤ: www.habr.com