스프링(운영체제)

봄

개발자	Sun Microsystems
OS 패밀리	Unix와 같은
동작 상태	단종
초기 릴리즈	1993년; 29년 전(1993년)
이용가능기간:	영어
갱신 방법	소스 코드에서 다시 컴파일
플랫폼	모토로라 68000 시리즈
커널 타입	마이크로커널

Spring은 1990년대 초 Sun Microsystems에서 개발한 실험적인 마이크로커널 기반 객체 지향 운영체제(OS) 구축 프로젝트입니다.마하 커널에서 개발된 개념과 실질적으로 유사한 기술을 사용하여 Spring은 다중 상속 및 기타 기능을 지원하는 보다 풍부한 프로그래밍 환경을 제공하는 데 주력했습니다.또한 Spring은 호스팅하는 운영 체제와 보다 깔끔하게 분리되어 Unix의 뿌리에서 분리되고 여러 OS를 동시에 실행할 수 있게 되었습니다.1990년대 중반 개발은 점차 중단되었지만, 이후 자바 프로그래밍 언어 라이브러리와 Solaris 운영 체제에서 몇 가지 아이디어와 일부 코드가 재사용되었습니다.

역사

봄은 1987년에 Sun과 AT&T가 합병한 UNIX를 만들기 위한 협력의 일환으로 우회적인 방식으로 시작되었습니다.양사는 또한 "객체 지향적인 방식으로 ^[1]UNIX를 재실장할 수 있는 좋은 기회"라고 판단했습니다.그러나 불과 몇 번의 회의 끝에 프로젝트의 이 부분은 중단되었다.

Sun은 팀을 유지하기로 결심하고 대신 최첨단 시스템을 개발하기로 했습니다.Unix의 플레이버를 조합하는 것에 가세해, 새로운 시스템은 다른 거의 모든 시스템을 분산적으로 실행할 수 있게 됩니다.이 시스템은 1993년에 처음으로 "완전" 방식으로 가동되어 일련의 연구 논문을 작성했다.1994년에는 비상업 라이선스로 "연구품질"이 발표되었지만 얼마나 널리 사용되었는지는 불분명하다.팀은 해체되어 Sun 내의 다른 프로젝트로 이동했으며, 스프링 컨셉을 다양한 다른 프로젝트에 사용했습니다.

배경

스프링 프로젝트는 마하 3가 출시된 직후에 시작되었다.이전 버전에서는 마하(Mach)는 단순히 기존 BSD 커널의 수정 버전이었지만, 마하 3에서는 Unix 서비스가 분리되어 다른 프로그램과 마찬가지로 사용자 공간 프로그램(서버라고 하는 개념)으로 실행되었습니다.기존의 Unix 시스템에서는 커널 내에서 일반적으로 비공개였던 데이터는 이제 IPC(Inter-Process Communication) 시스템을 사용하여 서버와 사용자 프로그램 간에 전달되어 두 프로그램이 보유한 포트로 종료되었습니다.Mach는 이러한 포트를 커널에 구현하고 가상 메모리를 사용하여 프로그램 간에 데이터를 이동하며 메모리 관리 유닛(MMU)과 카피 온 라이트 알고리즘에 의존하여 적절한 성능을 구현했습니다.

궁극적인 개발 과정에서 마하 OS는 각각 특정 태스크를 처리하는 다수의 서버로 구성됩니다.예를 들어 파일 시스템 또는 네트워크 스택이 있습니다.이러한 시스템의 운영체제서버는 매우 작기 때문에 해당 OS에 고유한 서비스를 제공하고 다른 대부분의 콜을 다른 서버로 전송합니다.OS는 하나의 공통 서버 세트 위에서 실행되었기 때문에 여러 OS 서버를 동시에 실행할 수 있었고, 단일 시스템이 동시에 DOS, Unix 및 기타 운영 체제를 '네이티브하게' 지원할 수 있었습니다.

이 기능은 이미 여러 개의 다른 시스템을 지원하던 IBM과 같은 기업에게 특히 흥미로웠고, 마하(Mach)는 이러한 시스템을 공통의 기본 코드와 결합하는 방법으로 간주했습니다.사실 이것은 그렇게 쉽지 않았다.Mach는 낮은 수준에서 여러 가지 결정을 내렸고, 이로 인해 어느 정도 Unix와 같은 시스템이 실행되게 되었습니다.가장 주목할 만한 것은 상당히 융통성 없는 Unix 프로그램의 상속 모델을 모델로 한 보안 시스템입니다.또, IPC 시스템이 퍼포먼스의 큰 문제가 되고 있는 것이 판명되었습니다만, 이 문제의 성질은 나중에 밝혀졌습니다.성능이 너무 저조해서 기존 운영 체제, 특히 IBM의 Workplace OS를 마하로 이식하는 많은 상업 프로젝트가 결국 포기되었습니다.

근거

Sun은 여러 운영 체제를 지원하는 데에도 관심이 있었지만 IBM이나 Apple만큼 시급한 요구사항은 없었습니다.이 시점에서 이미 68k 기반의 초기 머신에서 SPARC 기반의 라인업으로 플랫폼을 옮겼고, UNIX System V 기반의 Solaris 운영체제는 BSD 기반의 SunOS를 계승하고 있었습니다.Sun의 우려는 다소 미묘했다: 개발자들이 Sun의 Unix 버전에 관심을 계속 가지도록 하고, 셋톱박스 같은 작은 기기로 시스템을 축소할 수 있도록 하는 것이다.마이크로커널 기반 시스템은 이 후자의 역할에서 특히 유용합니다.

스프링은 시스템 개발을 용이하게 하는 "프로그래머빌리티"에 중점을 두고 있습니다.이 점에 있어서 주된 추가는 리치 인터페이스 정의 언어(IDL)의 개발이었습니다.IDL은 마하보다 훨씬 많은 정보를 가진 인터페이스를 내보냈습니다.Spring의 인터페이스에는 함수와 그 파라미터 외에 어떤 오류가 발생할 수 있는지와 오류가 속한 네임스페이스에 대한 정보도 포함되어 있습니다.적절한 언어를 사용하면 운영체제서버를 포함한 프로그램은 여러 인터페이스를 Import하여 그 언어(특히 C++)에 고유한 오브젝트인 것처럼 결합할 수 있습니다.잠시 후 스프링 IDL이 CORBA IDL로 약간 변경되어 채택되었습니다.

Spring은 파일 시스템, 가상 메모리 및 IPC 퍼포먼스에 관한 많은 특정 소프트웨어 진보에 대해서도 설명했습니다.그 결과 단일 Unix와 유사한 시스템으로 마하보다 훨씬 뛰어난 성능을 발휘했습니다.이러한 변경 중 일부는 아래에 자세히 설명되어 있습니다.

묘사

Sun 엔지니어는 많은 공통 컴포넌트에 대해 비표준 용어를 사용했기 때문에 시스템에 대한 논의가 다소 혼란스러워졌습니다.예를 들어 마하 태스크는 도메인, 포트는 도어, 커널은 핵이라고 합니다.

핵

Spring 커널은 가상 메모리 시스템과 핵의 두 부분으로 나뉘었습니다.핵은 마하 커널의 일부에 불과하지만 각 OS의 커널은 동일한 기능을 수행하는 것으로 간주될 만큼 유사합니다.

Spring 커널에는 사용자측 애플리케이션을 지원하는 데 필요한 가장 기본적인 기능과 상태만 포함되어 있습니다.여기에는 주로 실행 중인 프로그램(도메인)과 스레드 목록 및 이들(도어) 간의 통신 링크를 유지하는 상태가 포함됩니다.

스프링 커널은 멀티 스레드가 아닙니다.통상, 이것에 의해, 리얼 타임 설정에서는 사용할 수 없게 됩니다만, 그 경우는 불명확합니다.일반적으로 커널은 디스크 I/O 등의 장시간 실행되는 태스크로 인해 시스템이 중단되어 후속 콜이 제시간에 처리되지 않도록 하기 위해 스레드화되어야 합니다.스프링에서는 커널이 대부분의 요구를 서버에 즉시 인계하기 때문에 이론상으로는 서버만 필요합니다.읽혔다.

IPC 모델

마하와 스프링의 주요 차이점 중 하나는 IPC 시스템입니다.마하에서는 이 시스템이 프로그램 간의 단방향 비동기 파이프(포트) 세트로 배열되었으며, 이는 Unix 파이프에서 파생된 개념입니다.그러나 프로그래밍에서 가장 일반적인 통신 방법은 프로시저 호출, 즉 호출/반환이며, 이는 마하(Mach)가 직접 지원하지 않습니다.콜/리턴 시멘틱스는 기본 포트 메커니즘에 기반한 상위 수준의 라이브러리에서 추가 코드를 통해서만 지원되므로 복잡성이 가중됩니다.

대신 스프링은 기본 통신 시스템에서 직접 콜/리턴 의미를 지원했습니다.그 결과 용어가 마하에서는 포트에서 봄에는 도어로 변경되었습니다.도어는 커널에만 알려져 있었고, 프로그램은 해당 프로그램에 고유한 식별자와 함께 도어에 "핸들"을 건네주었다.시스템은 첫 번째 메시지의 포트와 유사하게 작동했습니다. 문에 보낸 메시지는 대상 애플리케이션을 찾고 도어 핸들을 번역하기 위해 핵에 의해 검사되었지만 핵은 데이터를 신속하게 반환하기 위해 발신자로부터 소량의 정보를 기록했습니다.이로 인해 수익률이 약 40% 향상되었습니다.

또한 마하 모델은 비동기 모델입니다.서버에 데이터가 있는 경우 콜이 반환됩니다.이것은 서버가 사용 중일 때 다른 프로그램을 실행할 수 있는 파이프의 원래 Unix 모델을 따랐습니다.단, 콜/리턴 시스템에서는 작업스케줄러를 실행하여 다음 서비스 대상 프로그램을 선택해야 하기 때문에 중대한 단점이 있습니다.이것이 콜이 데이터를 요구하고 있는 서버라고 생각됩니다만, 이것은 보증되지 않았습니다.Spring에서는 IPC가 동기화됩니다.컨트롤은 스케줄러를 실행하지 않고 서버에 즉시 전달되므로 서버가 즉시 복귀할 수 있는 일반적인 경우 라운드 트립 시간이 향상됩니다.

마하에서는 메모리 관리 유닛(MMU)에 의해 지원되는 가상 메모리 시스템은 메모리 내의 동일한 데이터를 2개의 프로그램에 매핑하는 것만으로 데이터 복사에 대한 경량 솔루션을 제공할 것으로 기대되었습니다.많은 MMU가 설계 기능을 가지고 있어 매핑이 느리거나 불가능했기 때문에 실제로는 이 솔루션은 전혀 효율적이지 않았습니다.

IPC에 대한 마하의 일체형 솔루션과는 달리 Spring은 프로그램 간에 데이터를 물리적으로 전달하기 위해 다양한 방법을 사용했습니다.이들 중 하나인 벌크 패스는 기본적으로 Mach의 포트 및 메시지와 동일하지만 실제로는 벌크 패스가 가장 일반적인 메시지 유형입니다.작은 메시지의 경우 Spring은 한 공간에서 다른 공간으로 데이터를 직접 복사하는 바닐라 경로를 제공했는데, 이는 5k 미만의 데이터로 실제 메모리 매핑보다 더 빠른 것으로 입증되었습니다.

적어도 SPARC 기반 플랫폼에서 실행할 때는 고속으로 기동할 수 있습니다.패스트 패스는 마하 시스템을 괴롭히는 컨텍스트스위칭 오버헤드의 대부분을 피하기 위해 고유한 "하프 트랩"을 사용했습니다.스프링은 모든 프로세서 상태(커널에 트랩이 들어가는 경우 일반 절차)를 저장하지 않고 상위 16개의 SPARC 레지스터만 저장했습니다.이 숫자는 SPARC 아키텍처의 특정 구현 세부 정보에 의해 정의되었습니다.레지스터 스택의 다른 부분은 SPARC를 사용하여 리시버에 보이지 않게 렌더링되었습니다.WIM어느 정도의 보안을 제공하는 명령입니다.패스트 패스는 SPARC의 레지스터 창을 사용하여 콘텍스트를 한 프로그램에서 다른 프로그램으로 이동하는 일부 MMU 작업을 추가하는 단일 응용 프로그램 내의 고전적인 프로시저 호출과 매우 유사합니다.

패스트 패스를 사용할 수 있는 것은, 변환이 필요 없는(예를 들면, 도어 참조가 없는 등) 단순한 값을 건네는 콜의 경우 뿐입니다.최대 16개의 값을 사용할 수 있습니다.이것은 매우 제한적인 것처럼 보이지만, 실제로는 봄철 대부분의 콜(일반적으로 80% 이상의 콜과 약 60%의 리턴)에 의해 패스트 패스가 사용됩니다.반환은 디스크 블록과 같은 큰 데이터 블록으로 응답하는 경우가 많아 반환이 다른 IPC 시스템을 더 자주 사용하는 이유를 설명합니다.

32비트 SPARC V8 시스템에서는 패스트패스를 사용한 완전한 라운드 트립 콜이 100개 이상의 명령을 받았기 때문에 일반적인 마하 콜보다 몇 배 고속이 되었습니다.고속 패스가 다른 머신에 실장될 수 있는지는 불분명하기 때문에 스프링의 전체적인 성능 향상은 일반적으로 IA-32 시스템에서 측정되었던 마하와 비교하기 어렵다.구체적으로는 486DX-50에서는 기존 BSD Unix 시스템에서는 풀시스콜이 20밀리초 미만, 마하에서는 114밀리초 미만 소요되었습니다.이로 인해 50% 이상의 성능 적중률이 발생했으며 대부분의 마하 프로젝트는 실패했습니다.반면 SPARCstation 2에서는 패스트 패스를 사용한Spring의 IPC 시간은 11 µs에 불과했습니다.

가상 메모리

봄에 개선한 또 다른 주요 분야는 커널의 일부이기도 한 가상 메모리(VM) 시스템의 구현이었습니다.가상 메모리는 시스템, MMU 및 디스크 시스템의 물리 랜덤 액세스 메모리(RAM)를 결합하여 시스템 상의 모든 프로그램이 시스템 및 운영 체제가 지원할 수 있는 최대값과 동일한 자체 RAM 블록을 가지고 있는 것처럼 착각하는 시스템입니다.1980년대와 1990년대에 사용되었던 컴퓨터와 운영 체제에서 가장 널리 사용되는 메모리 주소 지정 모델은 이론적으로 4 GiB의 메모리 제한에 대한 액세스를 제공하는 32비트였지만, 2000년대 초까지는 비교적 비싼 컴퓨터만이 이 정도의 물리적 RAM을 가지고 있었습니다.VM 시스템은 RAM의 비활성 부분을 오프로드하는 데 사용되는 메모리 속도가 훨씬 느린 영역인 백업 저장소로 하드 디스크를 사용함으로써 더 많은 하드 디스크를 사용할 수 있다는 착각을 일으킵니다.

기존 Unix 시스템에서는 VM이 함께 연결된 디스크 및 메모리 핸들러와 마찬가지로 커널의 일부였습니다.마하에서는 VM 시스템을 어디에 배치할지가 명확하지 않습니다.커널이 RAM과 MMU를 제어하고 있지만 디스크 핸들러는 외부 클라이언트 프로그램의 일부입니다.이 문제를 해결하기 위해 Mach 3은 커널의 실제 VM 시스템을 제어하는 새로운 2층 VM 시스템을 도입했습니다.이 시스템은 외부 클라이언트 공간 호출기에 디스크 시스템과 상호 작용하여 메모리를 물리적으로 복사하도록 요구합니다.유감스럽게도 이는 심각한 성능 문제로 판명되었으며, VM 시스템의 다양한 계층이 서로 호출하기 때문에 커널을 여러 번 드나들거나 콘텍스트 스위치를 함께 사용해야 했습니다.

Spring 팀은 마하 모델에서 무엇이 잘못되었는지 조사하고 수정할 수 있는 장점이 있었습니다.그 결과, VM에 의해 다양한 메모리 객체에 매핑된 프로그램 내 주소 공간의 시스템이 훨씬 더 깔끔하게 분리되었습니다.이러한 객체들은 스토어 처리를 지원하는 호출기에 의해 관리되었습니다.프로그램에서 데이터를 요청하면 커널 내의 VM 시스템에 요청이 전달되고 VM 시스템은 적절한 호출기를 찾아 적절한 메모리 개체를 만들고 설정하도록 요청합니다.그 대신 호출기에는 VM에서 캐시 매니저가 전달되어 해당 메모리 객체의 로컬 캐시의 청결/더러운 상태를 추적합니다.구현 세부 사항으로 인해 이 모델이 상당히 복잡해졌지만, 이 대부분은 숨겨져 있었습니다.결국 기본 시스템은 메모리를 담당하는 호출기와 캐시를 담당하는 주소 공간을 가지고 있었습니다.두 회사는 데이터를 동기화하기 위해 명령을 주고받을 수 있는 잘 정의된 인터페이스를 가지고 있었습니다.

이러한 업무 분담은 매우 실질적인 성능 향상으로 이어졌습니다.프로그램은 메모리 개체를 공유할 수 있고 Spring과 같은 마이크로커널 시스템은 메모리를 복사하는 아이디어를 기반으로 하므로 Spring에서는 이러한 방식으로 메모리를 공유하는 프로그램도 VM 시스템에서 공유할 수 있습니다.따라서 마하에서는 네트워크 파일 서버가 프로그램에 데이터를 전송하면 두 프로그램 모두 VM 시스템의 메모리를 사용하게 됩니다.스프링에서는 메모리 오브젝트를 구현하는 호출기가 같은 메모리에 다른 핸들을 되돌리기 때문에 두 프로그램이 동일한 메모리 오브젝트를 자연스럽게 공유하게 됩니다.VM 내에서만 서로 다른 개체로 간주되며 별도의 캐시 매니저가 처리합니다.따라서 데이터는 RAM에 한 번만 캐시됩니다.이론적으로는, 이것은 실제의 RAM 사용율의 큰폭으로 향상할 가능성이 있습니다.

또한 API가 잘 정의된 외부 호출기를 사용하면 필요할 때 시스템을 완전히 분리할 수 있습니다.또한 Spring 프로그램은 자신을 포함하여 어떤 호출기가 자신의 요구에 가장 적합한지 스스로 기술할 수 있게 되어 Spring 프로그램은 알려진 워크로드에 대해 프라이빗 VM 시스템을 쉽게 구현할 수 있게 되었습니다.파일 서버, 웹 서버, 데이터베이스 관리 시스템과 같은 애플리케이션의 경우 커스텀 VM 및 파일 시스템을 사용하면 성능이 크게 향상되는 경우가 많습니다.

네임 서비스

대부분의 운영 체제에는 다양한 이름 지정 서비스가 포함되어 있습니다.가장 기본적인 예는 파일 시스템입니다.이 시스템에서는, 파일이 내부적으로는 작은 번호인 「핸들」에 의해서 참조되는 반면, 다른 디렉토리는 유저가 상호 작용하는 파일명을 지정합니다.같은 종류의 이름/식별자 이분법은 일반적인 Unix 시스템의 다른 많은 부분에서 발생합니다.프린터는, 다음의 URL 로 지정됩니다.etc/printcap파일, 환경변수의 작은 숫자와 문자열, DNS의 네트워크 위치. 이러한 시스템은 각각 고유한 이름과 커스텀 API를 제공하므로 개념상에서도 서로 다른 개체가 완전히 다르게 보입니다.

다른 시스템은 기존 Unix 시스템에 명명 시스템을 추가하려고 했지만, 일반적으로 이러한 다양한 서비스에서 모든 이름을 수집하여 하나의 컬렉션에 표시하는 기존 기능에 대한 "커버"였습니다.기본 시스템 레이아웃에 대한 지식이 필요했기 때문에 유연성이 떨어지는 경향이 있어 새로운 서비스를 쉽게 추가할 수 없었습니다.이것들은 별로 쓸모가 없었던 것 같다.

완전히 새로운 운영 체제에서만 범용 서비스를 제공할 수 있습니다.예를 들어 Plan 9에서는 파일 시스템을 범용 명명 서비스로 사용했습니다.프린터부터 윈도까지의 모든 것은 파일 시스템을 통해 이름으로 액세스할 수 있었습니다.이것은 원래의 Unix 개념의 확장으로, 몇 년 동안 기능이 점점 더 추가되면서 서서히 사라졌습니다.

Mach는 포트에 대해 어떤 종류의 명명 서비스도 가지고 있지 않았습니다.이것은 심각한 문제임이 판명되었습니다.왜냐하면 프로그램은 커널에 포트를 제공하도록 요구하기 위해 어떤 서버를 호출해야 하는지 사전에 알아야 했기 때문입니다.즉, 새로운 프린터 서버를 구 프린터 서버와 같은 포토에 배치하는 것은, 기능 교환이 필요 이상으로 어려운 일이었습니다.예를 들어, 개발을 위해서 2개의 서버를 나란히 실행할 수 있는 방법은 없습니다.포토를 이름으로 참조했을 경우, 서버는 다른 포토에 배치되어 같은 이름을 사용할 수 있습니다.네임 서버에서 제공하는 이 기능은 Spring에서는 매우 중요한 것으로 간주되었습니다.

Spring의 접근방식은 근본적으로 Plan 9 시스템을 뒤집었습니다.Spring에서는 파일 시스템은 단일 통합 이름 서비스를 사용하는 서버의 한 예입니다.동일한 서비스를 사용하여 디스크, 환경 변수, 하드웨어 장치, 프로그램 및 프로그램 내의 개체에 있는 파일 이름을 지정할 수 있습니다.시스템은 계층적이었지만system네임스페이스는 부팅 시 시작된 서버에 의해 직접 지원되었습니다.그 후, 다른 서버는, 알고 있던 이름을 시스템에 「바인드」해, 프린터 서버는 프린터 리스트를 작성해, 파일 시스템은 접속된 디스크의 디렉토리에 바인드 합니다.이와 같이 시스템상의 모든 객체의 매핑이 실행 시 구축되어 Plan 9와 매우 유사한 파일 형태로 액세스할 수 있습니다.이 모든 것은 단일 API를 사용하여 액세스할 수 있지만, 시스템은 특히 Unix 에뮬레이션 서버에서 클래식 서비스로 보이게 하기 위해 다양한 stub 라이브러리를 제공했습니다.

네임 서비스는 보안과 허가를 위한 중심 위치이기도 했습니다.봄철에는 실제 접근자인 문이 네임서비스에 의해 배포되기 때문에 서버는 완전한 접근통제 목록 기반의 허가 확인 시스템을 갖추고 있었다.따라서 파일 시스템에 대한 사용 권한을 제공할 뿐만 아니라 Spring에서는 동일한 사용 권한 및 사용자 인터페이스를 사용하여 모든 개체를 제어할 수 있습니다.예를 들어, 약 12개의 권한 시스템(파일 시스템, DCOM, SQL 액세스, IIS 등)을 포함하는 Windows NT와 비교해 보십시오. 이 모든 시스템은 개별적으로 설정해야 합니다.퍼포먼스를 향상시키기 위해 신뢰의 개념이 포함되어 네임서버가 다른 서버로부터의 요구가 유효하다고 생각할 수 있게 되었습니다.예를 들어 사용자가 파일서버에 파일액세스를 요구하면 시스템네임서버는 파일시스템에 요구를 전달하고 파일시스템에 즉시 전달합니다.다만, 유저를 알 수 없기 때문에, ACL 는 액세스 되고 있는 파일에 대해서 체크됩니다.

관련된 이름의 그룹을 컨텍스트라고 부릅니다.컨텍스트도 이름이므로 디렉토리의 파일시스템 개념과 비슷합니다.유저는, 전혀 관련 없는 오브젝트로부터 독자적인 콘텍스트를 작성할 수 있습니다.전혀 다른 드라이버(서버)를 사용하는 프린터를 1개의 리스트로 수집할 수 있습니다.또, 파일명이 다른 장소(또는 유저 마다)에 있는 경우도 있습니다.또, 검색 목적으로, 파일내의 모든 퍼스널 파일을 포함한 단일 도메인을 구축할 수도 있습니다.이와 같이 Spring은 기존의 Unixen에는 없는 유용한 기능인 파일 디렉토리를 "유니온"할 수 있도록 했습니다.

스프링에는 내장된 객체 지속성 시스템이 포함되어 있지 않지만 네임 서비스는 지속적이었고 이러한 방식으로 객체를 찾는 데 사용할 수 있었습니다.기동시에 기동하는 일련의 서버는, 같은 서버에 이름을 카피하고 있기 때문에, 기동 후에도 존속하는 네임스페이스가 어느 정도 제공되고 있었습니다.이론적으로 시스템은 네임 서버가 예를 들어 누군가가 요청할 때까지 네트워킹 서버를 시작하지 않고 "게으른 시작" 시스템을 제공할 수 있지만, 이 기능은 포함되지 않은 것으로 보입니다.실제로 네임스페이스를 분리하면 실제로 도어 네이밍을 구현한 서비스와 분리할 수 있어 구현이 상당히 쉬워집니다.

파일 시스템

앞서 설명한 바와 같이 스프링 VM에서는 어떤 호출기를 사용해야 하는지를 모든 프로그램에서 정의할 수 있습니다.또한 스프링 시스템은 단일 범용 명명 시스템을 기반으로 했습니다.이 두 가지 개념이 결합되어 Spring 파일 시스템이 생성되었습니다.

Spring 파일 시스템 운영의 핵심은 VM 시스템과의 긴밀한 통합이었습니다.VM 시스템이 파일 시스템에서 데이터의 로컬 캐시를 관리하는 것이 "알려진" 상태였기 때문에 파일 시스템은 명령 구조만으로 축소되었으며 자체 호출기였습니다.즉, 파일 시스템은 필요할 때 메모리 개체에서 데이터를 로드하고 저장하는 역할을 담당했지만, 해당 데이터의 캐싱은 VM에 의해 처리됩니다.앞에서 설명한 바와 같이 스프링에서는 시스템 내의 프로그램이 파일을 어떻게 공유하고 있는지에 관계없이 파일이 RAM에 한 곳에만 존재함을 의미합니다.

Spring은 대부분의 일반적인 Unix 시스템과 유사한 로컬 파일 시스템과 네트워크 장치용 캐싱 파일 시스템의 두 가지 파일 시스템을 사용했습니다.캐싱 시스템은 통상적으로 사용해야 하는 VM의 동일한 물리 메모리를 사용하여 Spring의 VM/pager 분할 유틸리티를 보여주고 CFS는 모든 읽기 요구를 로컬 캐시로 단락시키고 소스 파일 시스템에 30초마다 느린 쓰기 작업을 수행합니다.이것은, 일반적인 Unix 디렉토리가 네트워크를 개입시켜 로드되고 있는 경우, 특히 주목됩니다.이것은 워크스테이션의 랩의 통상적인 셋업입니다.대부분의 Unix 시스템은 동일한 성능상의 이유로 유사한 캐싱 메커니즘을 사용하지만, 결국 RAM을 두 번, 캐시에서 한 번, 그리고 이를 사용하는 프로그램에서 다시 사용하게 됩니다.또한 CFS는 리모트시스템에서 이름을 캐시하여 초기 디렉토리 트래버설 및 오픈 요구를 고속화합니다.

Spring 파일시스템은 네임서비스 컨텍스트프로바이더이기도 합니다.온디스크 구조의 디렉토리를 네임서비스의 새로운 컨텍스트에 쉽게 매핑합니다.그런 다음 범용 네이밍 API를 사용하거나 전통적인 유닉스 파일 시스템으로 제공하는 유닉스 에뮬레이션 라이브러리를 통해 접근할 수 있습니다.

Spring이 파일 시스템이라는 용어를 사용하는 것은 다소 혼란스럽습니다.일반적으로 이 용어는 디스크에 파일을 물리적으로 저장하는 특정 방법을 나타냅니다.

Unix 에뮬레이션

Spring은 또한 Sun의 비즈니스 기반인 기존 Unix 애플리케이션을 지원해야 했습니다.이를 위해 Spring은 두 가지 주요 확장기능을 탑재했습니다.완전한 Unix를 모방한 Unix 프로세스 서버와 Unix 커널 요구를 다양한 서버로 리다이렉트한 libc 라이브러리의 리라이트입니다.예를 들어, 파일 또는 네트워크 서비스가 필요한 Unix 애플리케이션은 관련 Spring 서버로 전송되며, 현재 실행 중인 프로그램을 나열하려는 애플리케이션은 Unix 프로세스 서버로 전송됩니다.또한 스프링에서는 아날로그가 없었던 개념인 신호 처리도 프로세스 서버가 담당했습니다.신호는 본질적으로 유연성이 없는 단일 목적의 IPC 메커니즘이기 때문에 하위 호환성 이외에는 실제로 필요하지 않았습니다.

Spring에서 Unix 애플리케이션을 실행하려면 libue에 대해 재링크해야 합니다.기본 Unix 유틸리티의 대부분과 X11 서버를 탑재한 시스템은 다시 링크되어 사용할 수 있습니다.그러나 이 호환성 방법은 눈에 띄지도 않고 동작할 것이라고 보증하지도 않았습니다.스프링 문서에서는 "많은" 어플리케이션은 수정되지 않은 상태로 실행되지만(아마도 재링크되지 않을 경우) 개발자가 어떤 종류의 문제를 예상해야 하는지에 대해서는 언급하지 않았습니다.

하청

Spring 그 자체와는 직접 관련이 없지만, 이 프로젝트에서 작업하는 Sun 엔지니어는 다양한 종류의 콜을 지원하기 위한 기존 메커니즘이 제대로 정의되어 있지 않다는 것을 발견했습니다.보다 풍부한 인터페이스를 제공하기 위해 그들은 하청 개념을 개발했습니다.

기타 시스템

Sun은 Solaris에 "Unixified" 버전의 Doors를 추가했습니다.

스프링 시스템 작업이 종료된 후 몇 년 동안 운영 체제 전반에 대한 작업은 기본적으로 종료되었습니다.시장이 Windows 및 Unix와 유사한 운영체제가 지배하는 세계로 빠르게 계층화되면서 다른 시스템에는 틈새 시장만 열려 있는 것으로 보입니다.게다가 마하 3의 저조한 성능으로 인해 많은 프로젝트들이 숨통이 트인 것 같습니다.

그럼에도 불구하고, 몇 가지 새로운 시스템이 있었다.특히 L4 마이크로커널은 Spring의 커널과 많은 기능을 공유합니다.특히 IPC용 동기식 콜/리턴 시스템도 사용하며 VM 모델도 유사합니다.L4는 지금까지 거의 커널 자체에만 집중해 왔습니다. Spring의 명명 서비스, 보안 모델 또는 파일 시스템과 유사한 것은 없습니다.

레퍼런스