[ Home | Freetime works | FreeBSD | KFUG ]
오늘날의 컴퓨터 시스템에서, 프로그래머는 이 목적을 커널이라 불리는 거대한 프로그램을 통해 구현한다. 이 프로그램은 모든 사용자 프로그램에서 억세스 가능해야 하기 때문에, 시스템에 기능을 첨가하는 것은 자연스러운 일이다. 프로세스 상호작용을 위한 유일한 모델은 커널이 제공하는 특별하고 개인적인 서비스이기 때문에, 아무도 기능을 첨가하기 위해 커널 이외의 다른 장소를 만들지 못한다. 시간이 흐를수록, 더 많은 것들이 커널에 첨가된다.
전통적인 시스템은 사용자가 시스템의 거의 모두를 이해하고, 시스템 안에서 특권 상황을 가질 수 있어야만 그에게 부속을 커널에 더하는 것을 허용한다. 새 부속을 더하는 일은 다른 프로그램을 테스트하는 것 보다 더 많은 고통스러운 편집-컴파일-디버그의 사이클을 요구한다. 이는 다른사람이 시스템을 사용하고 있는 동안은 할 수 없다. 버그는 보통 치명적인 시스템 붕괴를 유발하며, 나아가 다른사람이 시스템을 사용하지 못하도록 한다. 전체 커널은 보통 페이징이 불가능하도록 되어 있다(페이징 가능한 커널이 있지만, 어디가 페이징 가능한지를 결정하는 것은 어렵고, 에러가 나기 쉽다. 보통 이 메카니즘은 어렵고, 간단한 확장을 할 때 조차도 이 일을 어렵게 한다).
이 제한 때문에, 절대적으로 필수적이지 않는 한 전통적인 커널의 벽 뒤에 적절히 속하는 기능은 보통 시스템에서 빠져 있다. 열기/읽기/쓰기 인터페이스로 아주 잘 할 수 있는 많은 좋은 생각들이 전통적 시스템 안의 고유한 독점적인 본성의 문제 때문에 구현되지 못한다. 게다가 참을성 있게 새로운 생각을 구현하려는 사람들 사이에서조차 그들의 컴퓨터의 특권 유저인 사람들만 그렇게 하고 있다. 소프트웨어의 저작권 시스템은 라이센스받지 못한 사람들은 커널의 소스조차 보는 일을 방해하여 그 진흙탕을 더욱 어둡게 하고 있다.
몇몇의 시스템은 이 어려움을 해소하려고 노력했다. Smalltalk-80과 Lisp머신은 모두 이 문제를 해결하는 한 방법을 제시하였다. 시스템 코드는 사용자 코드와 다르지 않다. 모든 시스템은 사용자에게 억세스 가능하며, 필요하면 바뀔 수 있다. 두 시스템은 아주 쉬운 대체와 확장의 기능을 가진 언어로 만들어졌고, 비교적 성공적이었다. 그러나 그들 모두는 사용자와 프로그램을 서로 고립시키는 일에는 아주 안좋아서 OS설계의 중요한 목적 하나에는 실패했다.
Mach 3.0커널을 사용하는 대부분의 프로젝트는 OS설계의 바뀌기 어려운 경향을 그대로 갖고 왔다. 내부구조는 다르지만, 사용자와 시스템 사이에는 같은 무거운 장벽이 남아 있다. 단일서버(single-servers)들은 아주 만들기 쉬운 반면에 독점적 커널의 모든 결점을 이어받았다.
다중서버(multi-server)는 커널 기능을 잘 정의된 인터페이스의 논리적인 블록으로 나눈다. 잘 만들어지면 기능을 바꾸거나 더하는 일은 쉽다. 그래서 대부분의 다중 서버 프로젝트는 다소 낫다. 더 많은 시스템의 부분이 페이징 가능하게 된다. 시스템을 더 쉽게 디버깅할 수 있다. 새 시스템 부속을 다른 사용자를 방해하지 않고 테스트할 수 있다. 그러나 사용자와 시스템간의 장벽은 여전히 남는다. 아무도 특권 없이는 이 벽을 넘을 수 없다.
GNU Hurd는 반대로 시스템 코드의 영역이 될 수 있는 한 한정되게 설계되었다. 프로그램은 커널의 몇 안되는 필수적인 부분과 통신하면 된다. 시스템의 나머지는 동적으로 대체할 수 있다. 사용자는 그들이 원하는 시스템의 어떤 부분이라도 사용할 수 있으며, 다른 사람들이 이 장점을 이용할 수 있도록 스스로 이 부속을 쉽게 더할 수 있다. 사용자들이 서로의 서비스를 이용하기 위해 미리 상호이해가 필요하지도 않고, 임의 사용자의 서비스를 믿어서 시스템이 취약하게 되지도 않는다.
이를 위해 사용자는 서로와 통신하기 위해 써야 할 이들 시스템 부속을 등록하면 된다. 이들 중 하나는 사용자를 확인하는 일을 책임지며, 인증 서버(authentication server)라고 불린다. 서로를 확인하기 위해 프로그램은 각각은 그들이 믿는 인증 서버와 함께 반드시 통신해야 한다. 다른 부속은 전체적인 관리를 담당하는 수퍼유저에 의한 시스템 부속을 제어하며, 이는 프로세스 서버(process server)라 불린다.
모든 사용자 프로그램이 프로세스 서버와 통신할 필요는 없다. 이는 그 서비스를 필요로 하는 프로그램에만 필요하다. 이와 비슷하게 인증 서버는 서로간의 확인을 하고 싶어하는 프로그램에만 필요하다. 남은 서비스의 어떤 것도 특별한 상태를 필요로 하지 않는다: 네트웍 구현도, 파일시스템도, 프로그램 실행 메카니즘도(setuid를 포함한), 이외의 어떤 것도.
대부분의 서버는 파일을 여는 것으로 억세스된다. 보통 파일을 열 때에는 파일을 가진 디렉토리를 소유하는 서버가 가지는 파일에 관련된(associated) 포트를 연다. 예를 들어 디스크 기반 파일시스템은 보통 각각 열린 파일이나 디렉토리를 표현하는 많은 포트를 제공한다. 파일이 열리면, 서버는 새 포트를 만들고, 이를 파일과 연관시키고, 부른 프로그램한테 포트를 되돌려 준다.
그러나 파일은 그와 관련된 변환기를 가질 수 있다. 이 경우, 파일의 내용을 참조하는 포트를 돌려주는 대신 서버는 그 파일과 연관된 변환기 프로그램을 실행한다. 이 변환기에는 파일의 실제 내용을 가리키는 포트가 주어지고, 열기 동작을 완료하기 위해 원래 사용자에게 포트를 돌려주도록 요청한다.
이 메카니즘은 각 마운트 지점과 관련된 변환기를 갖는 일에 의해 mount에서 사용한다. 프로그램이 마운트 지점을 열면 변환기(이 경우에는 마운트된 파일시스템의 디스크 형식을 아는 프로그램)가 실행되고 포트가 프로그램에 돌려진다. 변환기가 시작한 후에는 이것이 종료하지 않는 한 다시 실행할 필요는 없다. 부모 파일시스템은 나중의 요청에 대비해 변환기로의 포트를 보존한다.
파일의 소유자는 특별한 권한 없이 변환기를 파일에 관련시킬 수 있다. 이는 어떤 프로그램도 변환기가 될 수 있다는 뜻이다. 분명히 시스템은 변환기가 파일 프로토콜을 정확히 구현하지 않으면 적절히 동작하지 않을 것이다. 그러나 Hurd는 최악의 결과가 중지할 수 있는 정지 상태(interruptible hang)가 되도록 설계되었다.
변환기를 사용하는 하나의 방법은 파일 프로토콜을 사용하여 계층적으로
구성된 자료를 억세스하는 것이다. 예를 들어 ftp프로그램의 사용자
인터페이스의 모든 복잡성은 없어졌다. 사용자는 FTP를 나타내는 특별한
디렉토리를 알기면 하면 원격 시스템을 억세스하기 위해 새로운 명령을
배우기 보다는 모든 표준 파일 관련 명령(예를 들어 ls나 cp)를 사용할 수 있다. 비슷하게 간단한 변환기는 tar나 gzip의 복잡성을 줄일 수 있다(이런 투명 억세스에는 약간의 대가가 추가되지만 편리하다).
XCreateWindow나 XDrawText)은 의미를 가지게 된다. 이 경우 파일시스템 프로토콜은 접촉점에 쓰이는 노드의 특성을 다루기 위해서만 사용한다. 노드는 I/O명령을 지원하지 않으며, 그런 메시지에느 message_not_understood 리턴 코드를 돌려준다.이 변환기 기법은 계층적 파일시스템과 같이 구성되지 않은 Hurd의 대부분의 서비스에 접촉하기 위해 사용한다. 예를 들어 암호의 교환을 위해 인증 꼬리말(authorization tags)을 사용하는 암호 서버에 이런 방식으로 접촉한다. 또한 네트웍 프로토콜 서버는 이런 형식으로 접촉할 수 있다. Roland McGrath가 변환기의 이런 사용법을 생각해 냈다.
Hurd는 다른 디렉토리의 개념적인 집합인 디렉토리를 만드는 변환기를 가질 수 있다. 이는 실행하고 싶어하는 모든 프로그램을 포함하는 하나의 디렉토리를 사용자에게 제공하는데 쓰일 수 있다. 이 주제에 대한 여러 가지 유용한 변종들이 있다.
암호 서버나 setuid 실행을 허락하는 변환기와 같은 변환기는 특별한 권한을 필요로 한다. 이 변환기들은 누구나 시행할 수 있지만, 이들은 루트가 소유한 노드 위에 설정되어야만 이들의 모든 서비스를 성공적으로 제공할 수 있을 것이다. 이는 어떤 사용자라도 reboot 시스템 콜을 부를 수 있다는 말과 같지만, 그 사용자가 루트이어야만 이를 존중한다.
Hurd에서는 사용자는 전통적 시스템에 의해 미리 정해진 거의 모든 것을 바꿀 수 있다. 작업 주소 공간과 특성 위의 Mach커널이 제공하는 수많은 제어와 함께 Hurd는 최초로 다른 사용자를 방해하지 않고 그들이 싫어하는 시스템의 일부를 바꿀 수 있는 시스템을 제공한다.
지금까지의 대부분의 Mach기반의 OS는 새 환경에서 대부분 같은 낡은 유닉스의 더 넓은 집합을 구현해 왔다. 반대로, GNU는 이 의미를 확장하여 사용자가 이를 개선하고 빼고 대체할 수 있도록 한다.
인증 서버는 세가지 서비스를 제공한다. 첫번째로 이는 인증 포트에서 간단한 부울(boolean) 연산을 제공한다: 주어진 두개의 인증 포트에서, 이 서버는 uid와 gid의 두 집합을 나타내는 세번째 포트를 제공한다. 두번째로, 이 서버는 임의의 인증 포트를 만들기 위해 uid 0의 어떤 사용자도 허용한다. 마지막으로 이 서버는 서로 믿지 못하는 클라이언트와 서버가 그들을 확인하고 서로에게 초기 정보를 넘겨주는 것을 허용하는 RPC(다른 프로그램과 아마도 다른 호스트간의 원격 프로시저 콜(Remote Procedure Calls))를 제공한다. 이는 파일시스템과 I/O프로토콜의 보안에 중요한 것이다.
어떤 사용자도 인증 프로토콜을 구현하는 프로그램을 쓸 수 있다. 이는 시스템의 보안을 위반하지 않는다. 서비스가 사용자의 인증을 필요로 할 때에는 이는 이것의 믿을 수 있는 인증 서버와 통신한다. 만약 그 사용자가 다른 인증 서버를 사용하면, 처리(transaction)는 중단되고 서버는 더이상 통신하기를 거부할 수 있다. 사실 이는 시스템의 모든 프로그램이 같은 인증 서버를 사용하도록 강제하기 때문에, 우리는 이 인터페이스를 어떤 안정한 동작이라도 가능하고 관계없는 명령을 포함하지 않도록 인터페이스를 설계했다(이것이 분리된 암호 서버가 있는 이유이다).
세번째로 프로세스 서버는 Mach 작업(task)와 Hurd 프로세스 사이의 일대일
사영(mapping)을 관리한다. 모든 작업은 pid를 할당받는다. 프로세스는 이
서버에 메세지 포트를 등록할 수 있고, 이 포트는 요구하는 어떤
프로그램에게도 제공될 수 있다. 이 서버는 이 메세지 포트를 사적으로
만들려는 어떤 시도도 하지 않으며, 따라서 사용자 프로그램은 필요한
보안사항은 스스로 구현해야 한다(GNU C라이브러리는 이 모든 것을 위해
편리한 함수를 제공한다). 프로세스는 프로세스 서버에게 현재의 'argv'와
'envp'값을 알려줄 수 있다. 그런 후 이 서버는 요청에 따라 인수와
환경변수에 대한 벡터를 제공할 것이다. 이는 ps와 같은
프로그램을 쓰기에 유용하고 이 정보를 숨기거나 바꾸는 일도 쉽게 할 수 있다. 이 어떤 것도 필수적이지는 않다. 프로그램은 이 모든 것을 무시하고 자신을 프로세스 서버에 전혀 등록하지 않을 수 있다. 그러나 여전히 부여받은 pid는 가질 것이다.
마지막으로, 프로세스 서버는 동시에 많은 프로세스 메세지 포트를 모으는데 사용하는 프로세스 수집(Process Collection)을 구현한다. 또한 pid와 프로세스 서버 포트와 Mach작업 포트간의 변환기능이 제공된다. 반면에 포트의 보안을 유지하는 일을 확실히 한다.
프로세스 서버가 부가적이라는 것을 강조하는 일은 중요하다. Mach의 제한 때문에 프로그램은 시스템의 모든 작업을 확인하기 위해 루트로 실행되어야 한다. 그러나 다중 프로세스 서버가 각각의 클라이언트들과 함께 공존할 수 있다면 그들만의 세계 모델을 제공할 수 있다. 구현하기 위해 루트 권한을 요구하지 않는 이 프로세스 서버 기능은 사용자당 서버가 될 수 있다. 사용자는 어떤 일이든 할 수 있다.
ange-ftp패키지는 모든 Emacs파일관련 명령에서 가상적으로 투명하게 FTP파일을 억세스할 수 있게 한다. 투명 FTP는 같은 일을 하지만 시스템 차원이다. 이 서버는 아직 다 되지 않았다. 자세한 것은 아직 더 만들어야 하지만, 확실히 바뀔 것이다.
BSD커널에서는 투명 FTP파일시스템은 Hurd에서보다 더 만들기 어렵지는 않다. 그러나 이 개념을 BSD해커에게 이야기하니 반응은 "그런 건 커널에 속하지 않는다" 라는 것이었다. 어떤 의미에서는 이 말은 옳다. 이런 것이 커널 안에 놓이는 것은 시스템의 모든 계층화 원칙을 위반한다. 그러나 이 불행한 부수 효과는 설계 방법론(사용자가 좋아하지 않은 것을 바꾸지 못하도록 하는일에 기반한)이 시스템 설계자가 더 좋게 하는 일을 방해하는데 사용한다(최근의 BSD커널은 투명 FTP를 제공하는 사용자 프로그램을 쓸 수 있게 한다. 그 예는 alex인데, 실행하기 위해서는 루트권한을 요구한다).
Hurd에서는 투명 FTP를 하기 위한 장애물은 없다. 변환기는 /ftp노드에 제공할 수 있다. /ftp의 내용은 있을 것이지만 아마도 직접 볼 수는 없을 것이다. 이는 여러 가능한 형식이 될 수 있다. 예를 들어 uunet의 파일을 억세스하기 위해서 cd /ftp/ftp.uu.net:anonymous:mib@gnu라고 할 수 있다. 또는 원격 계정의 파일을 억세스하기 위해서 cd /ftp/gnu.ai.mit.edu:mib:passwd라고 할 수 있다. 이 명령의 일부는 삭제되며 투명 FTP프로그램은 사용자의 .netrc파일을 읽을 수 있다. 마지막 경우에서 cd /ftp/gnu.ai.mit.edu라고 하면 나머지는 이미 .netrc에 있게 된다.
cd를 먼저 할 필요는 없다 - 어떤 파일 명령이라도 사용하자. RFC 1097(the Telnet Subliminal Message Option)에 대해 찾기 위해서는 단지 more /ftp/ftp.uu.net/inet/rfc/rfc1097이라고 치면 된다. RFC를 자주 읽어야 한다면 지역 디스크로 복사할 수 있다.
네트웍 파일시스템 프로토콜은 시작점으로 4.4BSD를 사용하여 구현될 것이다. 기록 구조(log-structured) 파일시스템은 스프라이트(Sprite)에서처럼 같은 개념을 사용하여 구현될 것이지만, 아마도 같은 형식은 아닐 것이다. GNU 네트웍 파일 프로토콜이 곧 설계되던지 NFS가 결점을 제거하기 위해 확장될 것이다. GNU와 다른 OS간에 파일을 옮기고 싶은 사람들을 돕기 위해 MS-DOS파일시스템과 같은 여러 조그만 파일시스템이 있을 것이다.
프로그램은 여러가지 방식으로 통신 채널에 터미널 드라이버를 추가할 수 있을 것이다. rlogind와 같은 서버는 네트웍 통신 포트에 터미널 프로토콜을 추가할 수 있다. 오래된 프로그램의 하위 호환성을 위해 제공되겠지만 의사 터미널(pseudo-terminal)은 필요하지 않다. GNU의 어떤 프로그램도 이에 의존하지 않을 것이다.
터미널 드라이버의 어떤 것도 사용자에게 강요하지 않는다. 터미널 드라이버는 사용자가 내재한 통신 채널을 쉽게 얻을 수 있도록 하고, 필요할 때마다 또는 함께 자신을 지나칠 수 있고, 다른 터미널 드라이버과 같은 프로그램으로 대체할 수 있도록 한다. 마지막 경우에 대체 프로그램이 필요한 인터페이스를 구현한다면 보통 터미널 드라이버인 것처럼 정확히 C라이브러리에서 쓰일 것이다.
이 유연성때문에 원래의 터미널 드라이버는 복잡한 줄편집기능을 제공하지 않을 것이며, 자신을 POSIX와 BSD에서 찾을 수 있는 기능에 한정한다. readline기반의 터미널 드라이버가 만들어질 것인데, 이는 원하는 사용자를 위해 복잡한 줄편집기능을 제공할 것이다.
터미널 드라이버는 UUCP나 SLIP에서 필요한 큰 부피의 연속 데이터 전송 지원을 잘 하지 않을 것이다. 이 프로그램은 이들의 어떤 기능도 필요로 하지 않는다. 대신에 터미널을 위해 내장된 Mach장치 포트을 쓸 것인데, 이것은 많은 데이터의 전송을 효율적으로 지원한다.
execve시스템 콜의 구현은 세 프로그램 사이에 퍼져 있다. 라이브러리는 인수와 환경변수 벡터를 정리한다. 그러고서 이는 파일서버에 실행될 파일을 유지하는 메세지를 보낸다. 파일서버는 실행 권한을 점검하고 exec콜에 필요한 변환을 한다. 예를 들어 만약 파일이 setuid로 되어 있고 파일서버가 능력이 있으면 새 이미지의 사용자 확인을 바꿀 것이다. 또한 파일서버는 이전 작업에 억세스를 한 프로그램이 새 작업으로 억세스를 계속 해야 할 것인지 결정해야 한다. 파일서버가 권한을 증가하고 있거나 읽지 않은 이미지를 실행하면 exec는 보안을 유지하기 위해 새 Mach작업으로 대체할 필요가 있다.
새 이미지에 관련된 방법을 결정한 뒤 파일시스템은 exec서버에게 이 작업을 읽어들이도록 부른다. BFD(Binary File Descriptor)를 사용하는 이 서버는 이미지를 읽어들인다. BFD는 많은 객체 파일 형식을 지원한다. 거의 모든 지원하는 형식을 실행할 수 있을 것이다. 이 서버는 또한 #!으로 시작하는 스크립트를 다루고, 지시하는 프로그램을 통해 실행한다.
또한 표준 exec서버는 새 이미지의 환경변수를 본다. 만약 여기에 EXECSERVERS 환경변수가 있다면 시스템 기본값 대신 exec서버로 지정된 것을 사용한다(물론 파일서버가 안전하게 유지할것을 요구받은 exec에는 실행되지 않는다).
새 이미지는 GNU C라이브러리에서 실행되며, exec서버에게 인수, 환경변수, umask, 현재 디렉토리 등을 얻도록 메시지를 준다. 이 어떤 추가적인 상태도 파일이나 exec서버에게 특별한 것은 아니다. 만약 프로그램이 바란다면 라이브러리에서 다른 방식으로 사용할 수 있다.
fork시스템 콜은 GNU C라이브러리에서 거의 다 구현되었다. 새 작업은 Mach커널 콜에 의해 만들어진다. C라이브러리는 이 이미지를 적절하게 상속되도록 정리한다. 새 작업은 프로세스 서버에 등록된다(필수적은 아니다). C라이브러리는 fork시에 부를 함수의 벡터를 제공한다. 한 벡터는 fork전에 불리고, 하나는 부모 프로세스에서 나중에, 하나는 자식 프로세스에서 나중에 불린다(이 기능은 일반적인 fork-콜 순서를 대체하기 위해 쓰이지는 않는다. 이는 fork가 일어나기 전에 포트를 닫거나 지워야 하는데 필요한 라이브러리를 위한 것이다). C라이브러리는 진행중인 POSIX.4a에 정의된 두개의 fork 콜을 구현한다(스레드 확장에서 실시간 확장으로 다루는 제안된 표준).아무것도 사용자에게 이런 방법으로 작업을 만들라고 강요하지 않는다. 프로그램이 약간의 특징과 함께 거의 보통 fork만 사용하려고 하면 그렇게 할 수 있다. 후크는 C라이브러리가 제공할 것이고, 함수는 완전히 대체될 수도 있다. 이들 중 어느것도 전통적인 유닉스 시스템에서 가능하지 않다.
프로세스의 프로세스 그룹이 바뀌면 프로세스 서버는 새 프로세스 그룹을 지시하는 신호를 보낼 것이다. 이 경우 프로세스 서버는 작업의 커널 포트를 제공하여 그 권위를 확인한다.
C라이브러리는 또한 현재 프로세스에 의해 사용되는 uid를 더하고 지우기 위한 메세지를 갖는다. 프로그램에 새 uid가 보내지면 라이브러리는 이를 현재 집합에 더하고 새 인증을 밝히기 위하여 그가 아는 모든 I/O서버와 메세지를 교환한다. 비슷하게 메세제는 uid를 지울 수 있다. 후자에서 부른 이는 프로세스의 작업 포트를 제공해야 한다(권한을 더 주어서 프로세스에 해를 입힐 수는 없지만 권한을 빼앗을 수는 있다). Hurd는 사용자 프로그램이 이 메세지를 프로세스에게 보내는 기능을 제공한다. 예를 들어 su명령은 현재의 로그인 세션의 모든 프로그램이 서브쉘을 만들어내기 보다는 새 uid를 얻게 할 수 있다.
C라이브러리는 프로그램이 인식하고 싶어하는 비동기 메세지를 더할 수 있게 하며, 또한 표준 집합을 인식할 수 없게 하는 일을 허가한다.
어떤 환경에서는 바이너리 호환도 지원할 수 있다. 이 작업은 프로세스의 어드레스 공간 어딘가에 적재되는 특별한 버전의 라이브러리를 만드는 것으로 동작한다(예를 들어 VAX에서는 이는 스택 위에 넣게 된다). 시스템 콜 전환(system call redirection)이라 불리는 Mach의 특징은 이때 유닉스 시스템 콜을 가로채어 이 특별한 버전의 라이브러리로 바꾸게 하는데 쓰인다(거의 모든 기계에서 이런 전환에 드는 비용은 아주 작다. 이는 Mach에서 아주 최적화된 길이다. 386에서는 약 20개의 명령인데, 이는 간단한 프로시저 콜보다 조금 나쁠 뿐이다).
신호 마스크와 벡터(signal masks and vectors)와 같은 유닉스의 많은 특징은 라이브러리에 의해 완전히 다루어진다. 이는 그런 특징을 유닉스에서보다 아주 싸게 구현하도록 한다. 다른 비용이 많이 드는 방법을 찾아내느니 임계지역(critical sections)을 보호하기 위해 sigblock을 확장하여 사용하는 것이 합리적이다.
최적 성능을 내기 위해 초고속 I/O를 위해 제공되는 Hurd의 특징을 이용하는 작업이 필요하다. 대부분의 프로토콜에서 이는 약간의 생각을 필요로 하지만 많은 시간을 들이지는 않는다. Hurd는 TCP/IP프로토콜을 될 수 있는 대로 효율적으로 운영하게 될 것이다.
Hurd설계의 유연성의 흥미있는 예제로 BSD에서 성능을 위해 확장하여 쓰이는 IP트레일러의 경우를 생각해 보자. Hurd는 트레일러를 보내고 받게될 것이지만, 이렇게 하여 얻을 수 있는 장점은 거의 없는데, 복사될 데이터의 요구가 없고 페이지 정렬된 데이터의 복사를 피하는 것은 부적절하기 때문이다.
$Id: index.shtml,v 1.1.1.1 2001/05/23 03:10:44 cjh Exp $
[ Home | Freetime works | FreeBSD | KFUG ]