DNIX

DNIX
DNIX
개발자데이터 더스트리에 AB
OS 패밀리Unix와 같은
동작 상태단종
소스 모델폐쇄 소스
최신 릴리즈5.4
이용가능기간:영어
면허증.독자 사양

DNIX(원래 철자: D-Nix)는 스웨덴 기업 Dataindustrier AB(DIAB)에서 단종된 Unix와 유사한 실시간 운영 체제입니다.ABCenix라는 이름의 버전은 룩소르의 ABC 1600 컴퓨터를 위해 개발되었습니다.Daisy Systems는 또한 일부 CAD 워크스테이션에 Daisy DNIX라는 이름의 시스템을 가지고 있었습니다.DIAB 제품과는 무관합니다.

역사

스웨덴 DIAB에서의 개시

DIAB DS90 및 D-NIX용 시스템바인더

Dataindustrier AB(직역: 컴퓨터 산업 지분회사)는 1970년 스웨덴 Sundsvall에서 싱글보드 컴퓨터 제조업체로 시작되었으며, Data Board 4680이라는 이름의 Zilog Z80 [clarification needed]기반 컴퓨터를 생산했습니다.1978년 DIAB는 스웨덴의 Luxor AB와 협력하여 가정 및 사무실 컴퓨터 시리즈 ABC 80과 ABC 800을 제작하기 시작했습니다.

1983년 DIAB는 Motorola 68000 CPU를 기반으로 한 최초의 Unix 호환 머신 DIAB DS90을 독자적으로 개발했습니다.여기서 D-NIX는 AT&T Corporation의 UNIX System V 라이선스에 근거해 등장했습니다.그러나 DIAB는 산업용 제어 시스템(자동화) 회사였고 실시간 운영 체제가 필요했기 때문에 AT&T가 제공하는 UNIX 커널을 자체 개발되었지만 호환성이 있는 실시간 변종으로 교체했습니다.이 커널은 Litton [1][2]Industries의 Monroe Systems 부문용으로 작성된 OS.8이라는 이름의 Z80 커널에서 영감을 받았습니다.

시간이 지남에 따라 이 회사는 UNIX에서 코드가 파생되지 않은 UNIX 표준 사용자 공간 툴을 자체 구현으로 교체하여 AT&T UNIX 라이센스와는 독립적으로 머신을 도입할 수 있게 되었습니다.2년 후 Luxor와 협력하여 ABC 1600이라고 불리는 컴퓨터가 오피스 시장을 위해 개발되었으며, 이와 동시에 DIAB는 Motorola 68010, 68020, 68030, 그리고 최종적으로 68040과 같은 새로운 버전의 Motorola CPU를 사용하여 DS90의 향상된 버전을 계속해서 생산하고 있습니다.1990년 DIAB는 DIAB라는 브랜드명으로 DS 머신을 계속 생산 및 지원했으며 DIAB 2320, DIAB 2340 등의 이름으로 DIABs 버전을 여전히 실행하고 있습니다.[3]

ISC Systems Corporation 파생상품

ISC Systems Corporation(ISC)은 1980년대 후반에 DNIX를 Motorola 68k 기반의 은행 컴퓨터 라인에 사용할 수 있는 권리를 구입했습니다.(ISC는 나중에 Olivetti에 의해 인수되어 Wang에게 재판매되었고, 그 후 Getronics에 의해 인수되었습니다.ISC라고 불리는 이 법인체는, 몇년간에 걸쳐, 당황스러울 정도로 많은 이름에 회답해 왔습니다.)이 코드 브랜치는 SVR2 호환 버전이었고 광범위한 수정과 개발을 담당했습니다.이 운영 체제의 주목할 만한 기능은 요구 페이징, 디스크리스 워크스테이션, 멀티프로세서, 비동기 입출력(I/O), 파일 시스템 내의 디렉토리에 프로세스(핸들러)를 마운트하는 기능 및 메시지 전달을 지원하는 것이었습니다.실시간 지원은 목록 검색 메커니즘이 아닌 내부 이벤트 기반 큐('무리'),[4] 두 클래스의 정적 프로세스 우선 순위(완료까지 실행 및 타임슬릭), 연속 파일 지원(중요한 자원의 단편화를 방지하기 위한), 메모리 잠금으로 구성되었습니다.직교 비동기 이벤트 구현의 품질은 현재 상용 운영 체제에서는 아직 동등하지 않습니다(아직 채택되지 않은 개념은 모든 비동기 액티비티의 동기식 마샬링 포인트가 비동기식(ad ininitum)이 될 수도 있다는 것입니다).DNIX는 침착하게 대처했습니다.)비동기 I/O 기능은 하위 호환성을 위해 소켓 시멘틱스를 보존하는 소켓 에뮬레이션 라이브러리가 있었지만 버클리 소켓 선택 또는 SVR4의 STREAMES 폴링 메커니즘의 필요성을 배제했습니다.DNIX의 또 다른 특징은 표준 유틸리티(예: 빈번한 위반자인 ps)가 커널의 메모리 내에서 작업을 수행하기 위해 검색되지 않았다는 것입니다.대신 시스템 호출이 사용되었으며, 이는 커널의 내부 아키텍처를 필요에 따라 자유롭게 변경할 수 있음을 의미합니다.핸들러 개념은 네트워크 프로토콜 스택을 커널 외부에 둘 수 있게 해 주었으며, 이는 성능 비용이 들지만 개발을 크게 완화시키고 전반적인 신뢰성을 향상시켰습니다.또한 외부 파일 시스템을 사용자 수준의 프로세스로 만들 수 있어 신뢰성이 향상되었습니다.메인 파일 시스템은 외부 프로세스일 수도 있지만(한때에는) 성능상의 이유로 커널에 도입되었습니다.이 DNIX가 없었더라면 비록 공식적으로 그렇게 개발되지는 않았지만 마이크로커널로 간주될 수 있었을 것이다.핸들러는 모든 유형의 '원어민' Unix 파일, 디렉토리 구조 또는 디바이스로 표시될 수 있으며 핸들러가 처리할 수 없었던 파일 I/O 요청은 핸들러가 마운트된 기본 핸들러를 포함하여 다른 핸들러에 전달될 수 있습니다.핸들러 접속은 파이프와 마찬가지로 파일시스템에 의존하지 않고 존재할 수도 있습니다.이것의 한 가지 효과는 커널 기반의 유사 단말 설비를 필요로 하지 않고 Text Terminal(TTY; 텍스트 단말)과 같은 디바이스를 에뮬레이트할 수 있다는 것입니다.

핸들러가 하루를 구한 예는 ISC의 디스크리스 워크스테이션 지원입니다.실장에서의 버그로 인해 워크스테이션에서 이름 있는 파이프를 사용하면 파일 서버에서 바람직하지 않은 자원 잠금이 발생할 수 있습니다.적절한 커널 수정을 개발할 수 있을 때까지 문제가 있는 명명된 파이프에 대한 필드 액세스를 위해 워크스테이션에 핸들러가 생성되었습니다.이 핸들러는 구현에 약 5킬로바이트의 코드가 필요했습니다.이는 중요하지 않은 핸들러가 클 필요가 없음을 나타냅니다.

ISC는 DIAB의 DS90-10 및 DS90-20 머신을 파일 서버로서 제조할 권리도 취득했습니다.그러나 멀티프로세서 DS90-20은 타깃 시장에서는 너무 비쌌고 ISC는 자체 서버를 설계해 DNIX를 포팅했다.ISC는, 이러한 파일 서버용으로 독자적인 GUI 베이스의 디스크리스 워크스테이션을 설계해, DNIX를 다시 이식했습니다.(ISC는 Daisy DNIX를 실행하는 Daisy 워크스테이션을 사용하여 DIAB의 DNIX를 실행하는 머신을 설계했지만, 제도 및 레이아웃 직원이 소프트웨어 직원에게 거의 말을 걸지 않았기 때문에 내부적으로는 거의 혼란이 없었습니다.게다가 하드웨어 설계 담당자는 어느 시스템도 사용하지 않았습니다."ISC에서는 컴퓨터를 만들고 사용하지 않습니다."와 같은 농담도 있었습니다.DNIX의 비동기 I/O 지원으로 워크스테이션에서 이벤트 기반 프로그래밍을 쉽게 수행할 수 있었습니다.이러한 프로그래밍은 리소스가 비교적 한정되어 있어도 정상적으로 수행되었습니다.(GUI 디스크리스 워크스테이션에는 7MHz 68010 프로세서가 탑재되어 있어 512K의 메모리만으로 사용할 수 있었습니다.이 중 커널은 약 절반을 소비했습니다.대부분의 워크스테이션에는 1MB의 메모리가 탑재되어 있었지만, 이후 2MB와 4MB의 버전과 10MHz의 프로세서가 탑재되었습니다.)완전한 설치는 1대의 서버(16MHz 68020, 8MB RAM, 200MB 하드디스크)와 최대 64대의 워크스테이션으로 구성됩니다.이러한 어레이는 부팅이 느리지만 뱅크 텔러 애플리케이션에서는 정상적으로 동작합니다.DNIX의 타고난 효율성 외에도 DIAB C 컴파일러가 고성능의 핵심이었습니다.특히 ISC가 작업을 마친 후 68010에 대해 특히 좋은 코드를 생성했습니다(ISC는 이전 워크스테이션에서 사용된 Texas Instruments TMS34010 그래픽 코프로세서로 이 코드를 재설정했습니다).물론 DIAB C 컴파일러는 효율성에 기여하는 요소 중 하나였던 DNIX를 구축하는 데 사용되었으며, 어떤 형태로든 Wind River Systems를 통해 여전히 사용할 수 있습니다.

이 시스템은 2006년 현재도 사용되고 있으며, 현재는 Bank of America라는 브랜드가 된 이전 시애틀 퍼스트 내셔널 은행 지점에서는 사용되고 있습니다.다른 ISC 고객도 DNIX를 일부 용량으로 사용하고 있을 수 있습니다.ISC를 통해 중남미에서 상당한 규모의 DNIX가 존재했습니다.

비동기 이벤트

DNIX의 네이티브 시스템 콜은dnix(2)라이브러리 함수, 표준 Unix와 유사unix(2)또는syscall(2)기능.여기에는 여러 개의 인수가 필요했는데, 그 중 첫 번째 인수는 함수 코드였습니다.의미론적으로 이 단일 호출은 모든 적절한 Unix 기능을 제공했지만, Unix와는 구문적으로 다르고 물론 DNIX만의 확장도 다수 있었습니다.

DNIX 기능 코드는 다음 두 가지 클래스로 구성되어 있습니다.타입 1과 타입 2.타입 1 명령어는 I/O액티비티와 관련된 명령어 또는 발행 프로세스를 차단할 가능성이 있는 명령어입니다.주요 예는 다음과 같습니다.F_OPEN,F_CLOSE,F_READ,F_WRITE,F_IOCR,F_IOCW,F_WAIT,그리고.F_NAP타입 2는, 다음과 같은 나머지가 됩니다.F_GETPID,F_GETTIME커널에 의해 즉시 만족할 수 있습니다.

비동기성을 호출하려면 타입 2 opcode를 통해 트랩큐라고 불리는 특수한 파일 기술자를 작성해야 합니다.F_OTQ타입 1 콜에는, 다음과 같은 것이 있습니다.F_NOWAIT비트 OR-ed와 함수 값 및 추가 파라미터 중 하나:dnix(2)트랩 큐 파일 기술자였습니다.비동기 호출로부터의 반환값은 표준값이 아니라 커널에 의해 할당된 식별자입니다.비동기 요구가 완료된 시점에서 a,read(2)(또는F_READ트랩 큐 파일 기술자의 )는 식별자와 결과 상태를 포함하는 작은 커널 정의 구조를 반환합니다.그,F_CANCEL아직 완료되지 않은 비동기 작업을 취소할 수 있었습니다. 인수 중 하나는 커널에 의해 할당된 식별자입니다. (프로세스에서는 현재 자기 소유인 요청만 취소할 수 있습니다.취소의 정확한 의미론은 각 요청의 핸들러에 따라 결정되며, 기본적으로 모든 대기가 종료된다는 것을 의미합니다.부분적으로 완료된 작업이 반환될 수 있습니다.)커널에 의해 할당된 식별자 외에 비동기 조작에 주어지는 인수 중 하나는 32비트 사용자가 할당한 식별자입니다.이것은 I/O 완료 메서드를 처리하는 적절한 서브루틴에 대한 함수 포인터를 참조하는 경우가 가장 많았지만 이는 단순한 규칙이었다.이 값을 해석하는 것은 트랩큐 요소를 읽은 엔티티입니다. 

구조 동작하고 있다 {                   /* 트랩 큐에서 읽은 데이터 구조.*/         짧다   it_stat;        /* 상태 */         짧다   it_rn;          /* 요청번호 */         긴    oid;         /* 요청 시 소유자 ID */         긴    it_rpar;        /* 파라미터 */가 반환되었습니다. };

주목할 점은 비동기 이벤트가 일반 파일 기술자 읽기 작업을 통해 수집되었으며 이러한 읽기 또한 비동기적일 수 있다는 것입니다.이는 하나의 프로세스 내에 존재할 수 있는 반자율 비동기 이벤트 처리 패키지에 영향을 미칩니다.(DNIX 5.2에는 경량 프로세스나 스레드가 없습니다.)또, 주목해야 할 것은, 블록 조작의 가능성이 있는 경우는 모두 비동기적으로 발행할 수 있기 때문에, DNIX는 단일의 서버 프로세스로 많은 클라이언트를 처리할 수 있는 충분한 설비를 갖추고 있었습니다.프로세스에는 트랩큐가 1개밖에 없기 때문에 I/O 요구는 이 방법으로 우선순위가 매겨질 수 있습니다.

호환성.

원어민에 더해서dnix(2)call, 완전한 '표준' libc 인터페이스 콜 세트를 사용할 수 있었습니다. open(2),close(2),read(2),write(2)하위 호환성에 도움이 될 뿐만 아니라 NCR 타워 컴퓨터와 바이너리 호환 방식으로 구현되어 컴파일된 바이너리가 DNIX에서 변경되지 않습니다.DNIX 커널 내부에는 DNIX 방식용과 Unix 방식용 두 개의 트랩 디스패처가 있습니다.디스패처의 선택은 프로그래머에게 달렸고, 두 가지를 서로 교환할 수 있게 사용하는 것은 허용되었다.의미론적으로는 기능이 중복되는 모든 장소에서 동일했습니다.(이러한 기계에서는 68000이 trap #0명령어가 사용되었습니다.unix(2)콜 및trap #4에 대한 지시.dnix(2)2개의 트랩핸들러는 매우 비슷하지만 [보통 숨겨져 있습니다]unix(2)call은 프로세서의 D0 레지스터에 함수 코드를 보유하고 있는 반면,dnix(2)나머지 파라미터와 함께 스택에 보관되어 있습니다.)

DNIX 5.2에는 내부적으로 네트워킹 프로토콜 스택이 없습니다(ISC가 디스크리스 워크스테이션 지원 패키지로 사용하기 위해 추가한 X.25 기반의 Thin Ethernet Protocol 스택을 제외하고).모든 네트워킹은 핸들러에 대한 읽기 및 쓰기 방식으로 진행되었습니다.따라서 소켓메커니즘은 없었지만libsocket(3)비동기 I/O를 사용하여 TCP/IP 핸들러와 통신하는 것이 존재합니다.버클리로부터 파생된 일반적인 네트워킹 프로그램은 변경되지 않은 상태로 컴파일되어 실행될 수 있습니다(일반적인 Unix 포팅 문제 모듈화). 그러나 네이티브 비동기 I/O를 사용한 동등한 프로그램만큼 효율적이지 않을 수도 있습니다.

핸들러

DNIX에서는 I/O 요청을 처리하고 파일 시스템을 확장하는 프로세스를 사용할 수 있습니다.이러한 프로세스는 핸들러라고 불리며 운영 체제의 주요 기능입니다.핸들러는 적어도1개의 요구 큐를 소유하는 프로세스로 정의되어 있습니다.특수 파일 기술자는 다음 두 가지 방법 중 하나로 취득됩니다.F_ORQ또는F_MOUNT콜. 전자는 격리된 요청 대기열을 발명했고, 그 중 한쪽 끝은 일반적으로 자녀 프로세스로 전달됩니다.(많은 수의 네트워크 리모트 실행 프로그램은 이 방법을 사용하여 자녀에게 표준 I/O 경로를 제공했습니다.)후자는 파일 I/O 요구를 핸들러에 채택할 수 있도록 파일 시스템에 접속되어 있습니다.(네트워크 로그인 프로그램에서는 UNIX에서 로그인하는 시멘틱스에서는 아마도 관련되지 않은 여러 프로세스가 표준 I/O 패스를 자녀에게 제공하기 위해 이 방법을 사용했습니다.오퍼레이터로의 O패스).파일 시스템의 디렉토리에 마운트되면 핸들러는 해당 포인트에 대한 모든 I/O 호출을 수신합니다.

그런 다음 핸들러는 요청 대기열에서 커널에 의해 할당된 작은 요청 데이터 구조를 읽습니다.(이러한 판독은 핸들러의 작성자가 원하는 대로 동기 또는 비동기식으로 실행할 수 있습니다).그런 다음 핸들러는 각 요구에 부응하기 위해 필요한 모든 작업을 수행합니다(대부분 DNIX를 사용).F_UREAD그리고.F_UWRITE요청의 데이터 공간을 읽고 쓰기 위한 호출을 한 후 적절한 방법으로 요청을 종료합니다.F_TERMIN특권 핸들러는, 클라이언트로부터, 파일 시스템등의 하위 핸들러에의 개별의 요구에 대해서, 클라이언트의 권한을 채용할 수 있습니다.F_T1REQ부하 직원의 허가 체계를 재현할 필요가 없습니다.핸들러만으로 요구를 완료할 수 없는 경우,F_PASSRQ함수를 사용하여 한 핸들러에서 다른 핸들러로 I/O 요청을 전달할 수 있습니다.핸들러는 나머지 작업을 다른 핸들러에게 전달하기 전에 요청된 작업의 일부를 수행할 수 있습니다.핸들러가 스테이트 머신 지향인 것은 매우 일반적이기 때문에 클라이언트로부터의 요구는 모두 비동기적으로 처리됩니다.이것에 의해, 1개의 핸들러가 복수의 클라이언트의 요구를 동시에 입력할 수 있게 되어, 이러한 요구가 불필요하게 서로 차단되지 않게 됩니다.요구 구조의 일부에는 프로세스 ID와 그 priority가 포함되어 있기 때문에 핸들러는 이 정보에 근거해 최초로 작업 대상을 선택할 수 있었습니다.요구는 요구된 순서대로 작업을 수행할 필요가 없었습니다.이를 위해 요구 큐와 트랩큐를 모두 폴링하여 실제로 작업을 수행하기 위해 좌굴하기 전에 고려해야 할 작업이 더 있는지 여부를 확인할 수 있습니다. 

구조 인식하다 {                   /* 수신 요청 구조 */         짧다   ir_fc;          /* 기능 코드 */         짧다   ir_rn;          /* 요청번호 */         긴    ir_opid;        /* 오픈 또는 마운트 시 부여한 소유자 ID */         긴    ir_bc;          /* 바이트 수 */         긴    ir_upar;        /* 사용자 파라미터 */         긴    ir_rad;         /* 랜덤 주소 */         ushort  ir_uid;         /* 사용자 ID */         ushort  ir_filters.;         /* 사용자 그룹 */         time_t  ir_time;        /* 요청 시간 */         하지 않다   ir_nph;         하지 않다   ir_npl;         /* 노드와 프로세스 ID */ };

프로세스가 가질 수 있는 요구 큐의 수에 특별한 제한은 없었습니다.예를 들어, 이것은 chroot jails에 네트워킹 기능을 제공하기 위해 사용되었습니다.

예

핸들러의 유틸리티를 이해하기 위해 ISC 핸들러는 다음과 같은 목적으로 존재했습니다.

ISC의 확장

ISC는 5.2(SVR2 호환) 및 5.3(SVR3 호환) 버전의 DNIX를 모두 구입했습니다.구매 당시 DNIX 5.3은 DIAB에서 개발 중이었기 때문에 DNIX 5.2가 배치되었습니다.시간이 지남에 따라 ISC의 엔지니어들은 5.3 커널의 대부분의 기능을 5.2, 주로 공유 메모리와 IPC에 통합했습니다.따라서 DIAB와 ISC의 DNIX 버전 사이에는 몇 가지 다른 기능이 있었습니다.DIAB의 5.3은 ISC의 5.2보다 더 많은 SVR3 기능을 포함하고 있을 것입니다.또한 DIAB는 SVR4 호환 OS인 DNIX 5.4로 넘어갔습니다.

ISC에서 개발자들은 자신들의 요구와 Unix 산업의 일반적인 동향에 따라 DNIX 5.2 버전을 상당히 확장했습니다(커널과 관련된 기능만 나열됨).

  • 디스크리스 워크스테이션 지원.워크스테이션의 커널 파일시스템이 삭제되어 X.25 기반의 이더넷 통신 스텁으로 대체되었습니다.파일 서버의 커널도 리모트 요구를 수신하여 커널 프로세스 풀에 서비스를 제공하는 결합 컴포넌트로 확장되었습니다.단, 표준 핸들러는 이를 위해 작성되었을 수 있습니다(나중에 ISC는 DNIX 서버 대신 표준 SVR4 기반의 Unix 서버를 도입했습니다).이들은 X.25 STREAMS와 커스텀 작성 파일 서버 프로그램을 사용했습니다.구조 효율은 떨어지지만 사용되는 플랫폼의 물리적인 마력은 서버를 훨씬 빠르게 만들 수 있습니다.유감스럽게도 이 파일 서버 프로그램이 네이티브 DNIX 서버의 모든 기능을 지원하지 않았습니다.명명된 파이프 같은 까다로운 것들은 전혀 작동하지 않았다.이것은 명명된 파이프 핸들러 프로세스의 또 다른 정당성이었습니다).
  • ISC의 MMU 기능을 사용한gdb 워치포인트 지원
  • 파일 시스템에 대한 비동기 I/O가 실현되었습니다(원래는 차단되어 있었습니다).이를 위해 커널 프로세스(kproc 또는 스레드)가 사용되었습니다.
  • 트러스형 또는 스트레이스형 프로그램 지원.이를 위해서는 표준 Unix ptrace 싱글 스테핑 메커니즘의 버그 수정과 더불어 트레이서가 기존 프로세스에서 표준 싱글 스테핑 메커니즘을 사용할 수 있도록 임시 프로세스 채택 기능을 추가해야 했습니다.
  • SVR4 신호 메커니즘 확장주로 새로운 STOP 신호 및 CONT 신호용이지만 새로운 신호 제어 콜도 포함합니다.ISC에는 adb 및 sdb 디버거용 소스 코드가 없기 때문에 u-page는 변경할 수 없었습니다.따라서 새로운 신호는 차단되거나 기본 처리를 수신할 수 있었을 뿐이므로 검출할 수 없었습니다.
  • 네트워크 스니핑 지원이를 위해서는 단일 이벤트가 여러 I/O 요청을 충족할 수 있도록 이더넷 드라이버를 확장하고 혼합 모드를 지원하기 위해 소프트웨어에서 하드웨어 필터링을 조건부로 구현해야 했습니다.
  • 디스크 미러링이것은 디바이스 드라이버가 아닌 파일 시스템에서 실행되었기 때문에 서로 다른 디바이스를 미러링할 수 있습니다.작은 하드 디스크를 플로피에 미러링 하는 것은, 플로피를 이젝트하는 것이 디스크 에러를 일으키기 쉬운 방법이기 때문에, 미러링을 테스트하는 일반적인 방법입니다.
  • 파일 시스템에 대한 32비트 inode, 30자 파일 이름, 심볼릭 링크 및 스틱디렉토리 확장자/dev/zero, /dev/noise, /dev/stdXX 및 /dev/fd/X 디바이스가 추가되었습니다.
  • 프로세스 그룹 ID 목록(SVR4에서).
  • #! 스크립트를 직접 실행합니다.
  • ISC의 Z-80 기반의 VMEbus 통신 보드를 사용한 시리얼 포트 증설.
  • 이동 가능한 스왑 파티션.
  • 실행 중인 프로세스의 핵심 '덤프' 스냅샷.fuser 명령어 지원
  • 프로세스 리니스 함수.부동 우선순위를 구현하기 위한 관련 시간 공유 재우선순위 프로그램.
  • 프로세스를 '머그'하여 모든 메모리 리소스를 즉시 빼앗는 방법입니다.현재 작업 세트가 무엇인지 판별하는 데 매우 유용합니다. 현재 작업 세트를 사용할 수는 있지만 반드시 사용할 필요는 없습니다.이것은 프로세스의 메모리 맵의 모든 1024 페이지의 상태를 보여주는 GUI 유틸리티와 관련되어 있습니다.(이것은 ISC의 MMU에서 지원되는 메모리페이지 수입니다).사용 시 타깃프로세스의 라이프 사이클을 통해 타깃프로세스를 정기적으로 '머지'한 후 스왑된 메모리의 양을 확인합니다.이는 ISC의 운영 환경에서는 수명이 긴 몇 개의 프로세스만 사용하고 메모리 사용률을 제어하고 성능을 유지하는 데 중요한 역할을 했기 때문에 유용했습니다.

추가되지 않은 기능

1997년 ISC의 DNIX 개발이 사실상 중단되었을 때, 계획된 OS의 많은 기능이 논의되었습니다.

  • 공유 객체– DNET용 암호화기와 GUI의 이미징 라이브러리라는2개의 동적으로 로드된 라이브러리가 존재하지만 이 기능은 일반화되어 있지 않습니다.ISC의 머신은 가상 주소 공간이 일반적으로 부족한 것이 특징이었기 때문에 메모리 매핑된 엔티티를 광범위하게 사용할 수 없었습니다.
  • 경량 프로세스– 커널에는 이미 단일 MMU 콘텍스트를 공유하는 여러 스레드가 있어 이를 사용자 프로세스로 쉽게 확장할 수 있었습니다.API의 의미는 이 중 가장 어려운 부분일 것입니다.
  • Access-Control List(ACL; 접근컨트롤 리스트)– 스톡파일 시스템 상에 마운트된ACL 핸들러를 사용하여 구현하는 것은 간단합니다.
  • 다중 스왑 파티션– DNIX는 이미 선택한 볼륨 상의 빈 공간을 스왑에 사용하고 있습니다.다음 볼륨으로 넘어가기 전에 볼륨 상의 빈 공간을 모두 사용하지 않도록 하기 위한 관련 공간 제한과 함께 순차적으로 시도해야 하는 볼륨 목록을 쉽게 제공할 수 있습니다.
  • gdb 경유 리모트 커널 디버깅– 모든 부품은 일반적인 시리얼 포트 또는 커널의 내장 X.25 링크 소프트웨어를 사용하여 이더넷을 통해 실행되지만 조립되지는 않았습니다.
  • 68030 지원 – ISC의 시제품은 완성되지 않았습니다.2개의 프로세서 피기백 플러그인 카드가 구축되었지만, 68020보다 빠른 카드로는 사용되지 않았습니다.68020 소켓에 장착해야 했기 때문에 신뢰성이 떨어졌고 속도가 그다지 빠르지 않았습니다.패스트 콘텍스트스위칭 ISC MMU는 디세이블(및 제안된 생산 유닛에서는 모두 제외) 상태로 유지되며 대신 DS90-20의 MMU 코드의 파생 코드를 사용하여 68030의 내장형 MMU가 사용되었습니다.ISC MMU는 매우 효율적이며 32개의 상주 프로세스 간의 즉각적인 전환을 지원하지만 주소 지정성은 매우 제한되었습니다.68030 MMU는 프로세스 내에서 8MB 이상의 가상 공간을 허용했습니다.이것은 ISC MMU의 제한이었습니다만, 이 MMU의 속도는 전체적으로 그 속도를 웃돌고 있기 때문에, 68030 머신은 모든 면에서 고속이며, 보다 큰 프로세스를 지원할 수 있을 것으로 기대되고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Sjöström, Roland (1996). "1981 Introduktionen av ABC 800". Positionering under strategisk osäkerhet - Luxor Datorer och persondatorbranschen. Linköping Studies in Management and Economics, Dissertations no 30. Vol. 2. Linköping: Ekonomiska institutionen, Linköpings tekniska högskola. pp. 73–100. ISBN 91-7871-699-3. ISSN 0345-7524.
  2. ^ Sjöström, Roland (1996). "1982 Ökad konkurrens och specialisering". Positionering under strategisk osäkerhet - Luxor Datorer och persondatorbranschen. Linköping Studies in Management and Economics, Dissertations no 30. Vol. 2. Linköping: Ekonomiska institutionen, Linköpings tekniska högskola. pp. 101–122. ISBN 91-7871-699-3. ISSN 0345-7524.
  3. ^ Historyien om DIAB – Dataindustrier AB
  4. ^ Linux에서의 Accept() scalability