☰

"전통적인" Unix에서 Pipe(2) 시스템 호출이 작동하는 방식

tag-icon • tag-icon pipe history system-calls
"전통적인" Unix에서 Pipe(2) 시스템 호출이 작동하는 방식

이는 다음을 의미합니다 perldoc -f syscall.

문제가 있습니다 syscall(SYS_pipe()). 생성한 파이프의 읽기 끝의 파일 번호를 반환하지만상대방의 파일번호를 검색할 수 없습니다.. 를 사용하면 이 문제를 피할 수 있습니다 pipe.

그러나 이는 확인되지 않았습니다. 다른 시스템 호출과 마찬가지로 양쪽 끝을 완벽하게 검색할 수 있습니다 syscall.SYS_pipe

perl -e '
    require "syscall.ph";
    my $p = pack "i2";
    syscall SYS_pipe(), $p;
    print join(",", unpack "i2", $p), "\n"
'
3,4

Linux에서는 그렇습니다. 몇 가지 차이점에 주의하면 openbsd와 Solaris에서도 동일합니다(Solaris에서는 실제로 시스템 호출이 이므로 입니다 pipe2(2)) syscall 42, $p, 0.

fs/pipe.cLinux 커널 소스 코드의 주석은 다음과 같습니다.

/*
 * sys_pipe() is the normal C calling standard for creating
 * a pipe. It's not the way Unix traditionally does this, though.
 */

그렇다면 "전통적인" 방법은 무엇입니까? 이것이 현대 시스템에서도 여전히 적용됩니까?

답변1

Perl 문서의 이 단락은펄 5.004_041997년 9월. SYS_pipe당시 특정 Unix 커널이 어떻게 했는지 는 잘 모르지만 Unix V6의 원래 구현에서는 레지스터에 두 개의 파일 설명자를 반환한 다음 라이브러리 pipe구현에서는 해당 값을 정수 배열에 저장했습니다.V6 pipe(2)맨페이지이를 간략하게 문서화하려면 다음을 수행하십시오.

(파이프라인 = 42.)
시스템 파이프라인
(r0의 파일 설명자 읽기)
(r1의 파일 설명자 쓰기)

메시지 제출 대상:리눅스 패치다양한 sys_pipe구현을 통합하는 것도 다음과 같이 언급됩니다.

전통적인 UNIX 구현은 일반적으로 레지스터에 두 개의 파일 설명자를 반환합니다.

아마도 Perl의 논평은 syscall전통적으로 함수의 결과를 반환하는 데 사용되는 모든 레지스터(위의 r0, PC의 AX/EAX/RAX 등)는 Perl 코드에서 얻을 수 있는 파일 설명자 읽기를 반환한다는 사실에서 비롯된 것 SYS_pipe같습니다. r1에 반환된 값을 읽을 수 없습니다.

나는 아직도 이런 방식으로 파일 설명자를 반환하는 최신 시스템을 모릅니다. 또한 1997년에 얼마나 많은 Unix 시스템이 이런 동작을 했는지는 잘 모르겠습니다. 적어도 Solaris(2.6)는 그렇지 않았던 것 같습니다.

관련 정보