RTLinux

이 문서에는 일반적인 참조 목록이 포함되어 있지만 대응하는 충분한 인라인 인용이 없습니다. 좀 더 정밀한 인용문을 도입하여 이 글의 개선에 도움을 주시기 바랍니다.(2009년 6월) (이 템플릿메시지의 삭제 방법과 삭제 타이밍에 대해 설명합니다)

RTLinux는 Linux 운영체제 전체를 완전 프리엠프티브 프로세스로 실행하는 하드 실시간 운영체제(RTOS) 마이크로커널입니다.실시간 하드 속성을 통해 RTLinux 애플리케이션에서 로봇, 데이터 수집 시스템, 제조 공장 및 기타 시간에 민감한 계측기와 기계를 제어할 수 있습니다.그 디자인은 ^[1]특허를 받았다.비슷한 이름이지만 리눅스 ^[2]Foundation의 Real-Time 리눅스 프로젝트와는 관련이 없습니다.

RTLinux는 Victor Yodaiken, Michael Barabanov, Cort Dougan 등에 의해 뉴멕시코 광업 기술 연구소에서 개발되었으며, 그 후 FSMLabs에서 상용 제품으로 개발되었습니다.Wind River Systems는 2007년 2월에 FSMLabs 임베디드 기술을 인수하여 Wind River Linux용 Wind River Real-Time Core 버전을 출시하였습니다.2011년 8월 현재 Wind River는 Wind River Real-Time Core 제품 라인을 중단하고 RTLinux 제품에 대한 상업적 지원을 사실상 중단했습니다.

배경

주요 RTLinux 설계^[3] 목표는 상용 운영 체제에 하드 실시간 기능을 추가하여 두 ^[4][5]기능을 모두 갖춘 복잡한 제어 프로그램의 개발을 촉진하는 것이었습니다.예를 들어 상용 데이터베이스를 사용하여 웹 운영자 인터페이스를 내보낸 실시간 모터 컨트롤러를 개발할 수 있습니다.실시간 및 비실시간 기능을 지원할 수 있는 단일 운영 체제를 구축하는 대신, RTLinux는 실시간 운영 체제와 비실시간 운영 체제 간에 컴퓨팅 장치를 공유하도록 설계되었기 때문에 (1) 실시간 운영 체제가 비실시간 운영 체제에 의해 실행이 차단되지 않습니다.2개의 다른 환경에서 실행되는 컴포넌트는 데이터를 쉽게 공유할 수 있습니다.이름에서 알 수 있듯이 RTLinux는 원래 Linux를^[6] 비실시간 시스템으로 사용하도록 설계되었지만 결국 RTCore 실시간 커널이 Linux 또는 BSD(버클리 소프트웨어 배포) Unix와 함께 실행되도록 진화했습니다.

MERT(Multi-Environment Real-Time)는 Unix 시스템과 공존하고 있는 실시간 운영 체제의 첫 번째 예입니다.MERT는 기존 가상화 기술에 의존했습니다.실시간 커널은 호스트 운영체제(또는 하이퍼바이저), Bell Systems Unix는 게스트였습니다.RTLinux는 MERT 개념을 PC시대와 범용 하드웨어로 업데이트하기 위한 시도였습니다.또한 MERT의 성능 제한, 특히 가상화로 인한 오버헤드를 극복하기 위한 시도이기도 했습니다.

RTLinux는 가상 시스템에 게스트 OS를 캡슐화하는 대신 게스트 인터럽트 제어만 가상화했습니다.이 방법을 사용하면 실시간 커널에서 게스트 운영 체제를 스토리지 디바이스와 같이 직접 제어할 수 있는 시스템으로 변환할 수 있습니다.특히 게스트용 표준 드라이버는 소스 변경 없이 동작했지만 가상화 "훅"을 사용하기 위해 다시 컴파일해야 했습니다.반가상화를 참조하십시오.Unix 파이프는 실시간 및 비실시간 프로그램이 통신할 수 있도록 조정되었지만 공유 메모리 등의 다른 방식도 추가되었습니다.

프로그래머의 관점에서 보면 RTLinux는 원래 실시간 태스크용 작은 스레드 환경이었고 다른 모든 작업을 위한 표준 Linux 환경처럼 보였습니다.실시간 운영체제는 로드 가능한 커널 모듈로 구현되었으며, 게스트 인터럽트 제어를 가상화한 후 실시간 스케줄러를 시작했습니다.태스크에는 정적 우선순위가 할당되어 스케줄링은 원래 순수하게 우선순위에 따라 이루어졌습니다.게스트 운영체제는 우선순위가 가장 낮은 태스크로 통합되어 기본적으로 실시간 시스템의 유휴 태스크로 기능했습니다.실시간 작업이 커널 모드로 실행되었습니다.이후 RTLinux는 Portable Operating System Interface(POSIX) POSIX 스레드 애플리케이션 프로그래밍 인터페이스(API)를 채택하여 게스트 프로세스 내에서 실시간 스레드를 실행하는 사용자 모드에서 스레드를 생성할 수 있게 되었습니다.멀티프로세서 환경에서는 스레드가 프로세서 코어에 잠겨 게스트 스레드가 지정된 코어로 실행되지 않도록 할 수 있었습니다(실시간 처리용으로만 효과적으로 코어를 예약).

실행

RTLinux는 표준 Linux와 동일한 머신 상에서 특별한 실시간 태스크를 실행하고 핸들러를 인터럽트하는 기능을 제공합니다.이러한 태스크 및 핸들러는 리눅스가 수행하는 작업에 관계없이 실행해야 할 때 실행됩니다.하드웨어 인터럽트가 프로세서에 의해 검출된 순간부터 인터럽트 핸들러의 실행 개시 시점까지의 최악의 시간은 범용 x86(약 2000년) 상에서 실행되는 RTLinux에서 15 마이크로초 미만입니다.RTLinux 정기 태스크는 동일한 하드웨어 상에서 스케줄된 시간으로부터 35마이크로초 이내에 실행됩니다.이러한 시간은 하드웨어에 제한이 있으며 하드웨어가 개선됨에 따라 RTLinux도 개선될 것입니다.Standard Linux는 평균 퍼포먼스가 뛰어나고 POSIX 소프트 실시간 기능을 사용하여 밀리초 수준의 스케줄링 정밀도를 제공할 수도 있습니다.단, 표준 Linux는 밀리초 미만의 정밀도와 신뢰성 높은 타이밍 보증을 제공하도록 설계되어 있지 않습니다.RTLinux는 Linux "게스트"에 가상화된 인터럽트 컨트롤러와 타이머가 할당되고 다른 모든 하드웨어 액세스는 직접 실행되는 경량 가상 머신을 기반으로 했습니다.실시간 "호스트"의 관점에서 Linux 커널은 스레드입니다.결정론적 처리에 필요한 인터럽트는 실시간코어에 의해 처리되며 다른 인터럽트는 실시간스레드보다 낮은 우선순위로 실행되는 Linux로 전송됩니다.Linux 드라이버는 거의 모든 I/O를 처리했습니다.First-In-First-Out 파이프(FIFO) 또는 공유 메모리를 사용하여 운영 체제와 RTLinux 간에 데이터를 공유할 수 있습니다.

객관적으로

RTLinux의 주요 설계 목표는 시스템이 투과적이고 모듈러적이며 확장^{[citation needed]} 가능해야 한다는 것입니다.투명성은 열 수 없는 블랙박스가 없다는 것을 의미하며, 운영 비용은 결정 가능해야 한다.모듈화는 기능성을 생략할 수 있고 필요하지 않은 경우 그 기능의 비용을 지출할 수 있음을 의미합니다.확장성이란 프로그래머가 모듈을 추가하고 요건에 맞게 시스템을 조정할 수 있어야 한다는 것을 의미합니다.기본 RTLinux 시스템은 고속 인터럽트 처리를 지원합니다.일부 특정 애플리케이션의 요구에 보다 적합한 스케줄러로 쉽게 대체할 수 있는 단순한 우선순위 스케줄러를 갖추고 있습니다.RTLinux를 개발할 때 Linux와 그 강력한 기능을 통해 얻을 수 있는 이점을 극대화할 수 있도록 설계되었습니다.

핵심 컴포넌트

RTLinux는 소형 코어 컴포넌트와 옵션 컴포넌트 세트로 구성되어 있습니다.코어 컴포넌트를 사용하면 Linux 자체에서 지연 또는 프리엠프트할 수 없는 매우 낮은 레이텐시 인터럽트 핸들러 및 일부 저레벨 동기화 및 인터럽트 제어 루틴을 설치할 수 있습니다.이 코어 컴포넌트는 SMP를 지원하도록 확장되었으며 동시에 코어 외부에서 제공할 수 있는 일부 기능을 제거함으로써 심플화되었습니다.

기능들

대부분의 RTLinux 함수는 옵션 서비스와 추상화 수준을 제공하는 로딩 가능한 커널 모듈 세트에 있습니다.이 모듈에는 다음이 포함됩니다.

1. rtl sched - 다음에 설명된 "lite POSIX" 인터페이스와 원래 V1 RTLinux API를 모두 지원하는 priority 스케줄러.
2. rtl time - 프로세서클럭을 제어하고 핸들러를 클럭에 접속하기 위한 추상 인터페이스를 내보냅니다.
3. rtl posixio - 디바이스 드라이버에 대한 POSIX 스타일의 읽기/쓰기/오픈 인터페이스를 지원합니다.
4. rtl fifo - Linux 프로세스가 RT 컴포넌트를 읽고 쓸 수 있도록 디바이스 계층을 통해 RT 태스크 및 인터럽트 핸들러를 Linux 프로세스에 연결합니다.
5. semaphore - Jerry Epplin이 작성한 패키지.RT 태스크에 세마포 차단 기능을 제공합니다.
6. POSIX 뮤텍스 지원은 RTLinux의 다음 마이너버전 업데이트에서 사용할 수 있을 예정입니다.
7. mbuff는 RT 컴포넌트와 Linux 프로세스 간에 공유 메모리를 제공하기 위해 Tomasz Motylewski에 의해 작성된 기여 패키지입니다.

실시간 태스크

RTLinux 실시간 태스크는 Linux가 드라이버, 파일시스템 등에 사용하는 모듈 유형과 유사한 커널 모듈로 구현됩니다.실시간 태스크는 하드웨어에 직접 액세스할 수 있으며 가상 메모리를 사용하지 않습니다.초기화 시 실시간태스크(모듈)는 RTLinux 커널에 기한, 기간 및 릴리즈 시간의 제약을 통지합니다.

스레드

RT-Linux는 스레드 조작을 위한 POSIX API를 구현합니다.스레드는 다음 명령어를 호출하여 생성됩니다.pthread_create기능.의 세 번째 파라미터pthread_create는 스레드에 의해 실행되는 코드를 포함하는 함수입니다.

스레드 priority를 RTLinux로 설정해야 합니다.우선순위가 높은 스레드는 우선순위가 낮은 스레드보다 우선할 수 있습니다.예를 들어 스테퍼 모터를 제어하는 나사산이 있습니다.모터를 원활하게 움직이기 위해서는 엄격하게 일정한 간격으로 이 나사산을 시작해야 합니다.이 스레드에 높은 우선순위를 할당함으로써 이를 보장할 수 있습니다.예제 threads2.c에서는 다른 스레드priority를 설정하고 있습니다.스레드 priority 설정은 다음과 같은 코드로 이루어집니다.

인트 init_interface(무효) { pthread_attr_t 특성; 구조 스크래치 PARAM.; pthread_attr_init(&특성); PARAM..sched_priority = 1; pthread_attr_setschedparam(&특성, &PARAM.); pthread_create(&t1, &특성, &스레드 코드, "이것은 스레드 1입니다."); rtl_printf(스레드 1이 시작되었습니다.\n"); ... } 

프로그램의 출력은 다음과 같습니다.

스레드 1 시작 스레드 3 시작 메시지: this is thread 1 메시지: this is thread 2 메시지: this is thread 2 메시지: this is thread 1 메시지: this is thread 3 메시지: this is thread 3 메시지: this is thread 3 메시지: this is this thread 3 메시지: this this thread 3

스레드 2의 priority가 가장 높고 스레드 3의 priority가 가장 낮습니다.첫 번째 메시지는 스레드 2보다 짧은 시간 전에 시작되므로 중간 우선 스레드 1에 의해 인쇄됩니다.

「 」를 참조해 주세요.

• RTAI. RTAI는 "MyRTinux"라고 불리는 RTLinux의 변형으로 시작되었으며 이후 릴리스에서는 특허받은 RTLinux 가상화 기술을 사용하지 말 것을 저자에 의해 주장되었습니다^{[dubious – discuss]}.
• RMX(운영체제)
• SCHED_DEADLINE
• 제노마이
• 프리엠프션(컴퓨팅)
• 임베디드 시스템의 Linux
• 실시간 테스트

레퍼런스

원천

외부 링크

• RTLinux 동기화에 관한 문서
• Real-Time Linux.빅터 요다이켄과 마이클 바라바노프, 뉴멕시코 공과대학
• 오늘 아카이브에서의 RT 개념에 관한 기사(2013-01-28)