정의
훅 루틴(hook routine)은 OSEK/VDX 운영체제가 내부 처리 중 정해진 지점에서 불러 주는 사용자 정의 함수다. 인터페이스는 표준화되어 있지만 기능은 사용자가 채운다.[1]
OSEK/VDX 운영체제는 정적으로 구성되므로 응용이 커널 안쪽에 코드를 끼워 넣을 여지가 거의 없다. 훅 루틴은 규격이 그 여지를 한정해 열어 둔 장치이며, 시스템 기동과 종료, 오류 처리, 그리고 추적·디버깅과 컨텍스트 스위치의 사용자 정의 확장이 그 용도다.[1]
공통 성질
훅 루틴은 운영체제의 일부이지만 내용은 사용자가 구현한다. 운영체제가 구현에 따라 정해지는 특별한 문맥에서 호출하며, 모든 태스크보다 우선순위가 높고 범주 2 인터럽트 루틴에 인터럽트당하지 않는다. 인터페이스만 표준화되어 있고 훅 루틴 자체의 환경과 거동은 표준화되어 있지 않으므로, 훅 루틴은 대개 이식 가능하지 않다. 각 구현은 자기 훅 루틴의 규약을 문서로 밝혀야 한다.[1]
구성 언어에서 다섯 훅은 각각 불리언 속성으로 켜고 끈다 — STARTUPHOOK, ERRORHOOK, SHUTDOWNHOOK, PRETASKHOOK, POSTTASKHOOK이다. 오류 훅에서 서비스 식별자와 문맥 정보에 접근하는 매크로를 쓸지도 USEGETSERVICEID와 USEPARAMETERACCESS 속성으로 따로 켠다.[2]
호출 가능한 서비스의 범위
훅 루틴에서는 API 함수의 일부만 쓸 수 있다. 대부분의 운영체제 서비스가 허용되지 않으며, 이 제약은 시스템 복잡도를 줄이기 위한 것이다. 허용되지 않은 서비스를 훅 루틴에서 부르면 거동이 정의되지 않는다.[1] 서비스별 허용 범위는 OSEK 인터럽트 처리에서 다룬다.
다섯 훅과 호출 시점
| 훅 | 호출 시점 | 인자 |
|---|---|---|
| StartupHook | 운영체제 초기화가 끝나고 스케줄러가 돌기 전 | 없음 |
| ShutdownHook | ShutdownOS 서비스가 불려 시스템이 종료되는 중 | 오류 |
| ErrorHook | E_OK가 아닌 상태값을 반환하는 시스템 서비스의 끝, 태스크 레벨로 돌아가기 전 | 오류 |
| PreTaskHook | 새 태스크를 실행하기 직전, 단 그 태스크가 running으로 전이한 뒤 | 없음 |
| PostTaskHook | 현재 태스크의 실행이 끝난 뒤, 그 태스크가 running을 떠나기 전 | 없음 |
PreTaskHook과 PostTaskHook의 호출 시점을 상태 전이의 안쪽으로 잡은 것은 의도된 설계다. 훅이 도는 동안 태스크가 아직 또는 이미 running 상태이므로 GetTaskID가 유효한 태스크 식별자를 돌려주고, 그 덕분에 두 훅을 디버깅이나 컨텍스트 스위치 시간을 포함한 시간 측정에 쓸 수 있다.[1]
종료 시의 PostTaskHook
태스크가 실행 중인 상태에서 ShutdownOS가 불리면 PostTaskHook은 불릴 수도 있고 불리지 않을 수도 있다. 불린다 해도 ShutdownHook보다 앞인지 뒤인지는 정의되어 있지 않다.[1]
기동과 종료
프로세서 리셋 이후의 초기화는 구현의 몫이지만 규격은 표준화된 기동 절차를 제시한다. 리셋 직후에는 운영체제 문맥 없이 하드웨어 고유의 응용 소프트웨어가 실행되고, 이 이식 불가능한 구간은 application mode를 판정하며 끝난다. 이 판정은 안전상의 이유로 시스템 이력에 의존해서는 안 된다. 이식 가능한 구간은 판정한 모드를 인자로 StartOS를 부르며 시작한다.[1]
운영체제는 내부 기동 처리를 마친 뒤 — 스케줄러는 아직 돌지 않는다 — StartupHook을 부른다. 사용자는 여기에 운영체제에 의존하는 초기화 코드를 둔다. 시작된 모드에 따라 초기화 코드를 나눌 수 있도록 GetActiveApplicationMode 서비스가 주어진다. 훅이 반환하면 운영체제는 사용자 인터럽트를 켜고 스케줄러를 시작하며, 현재 application mode에 선언된 자동 시작 태스크와 알람을 시작한다. 태스크의 자동 시작이 알람의 자동 시작보다 먼저이며, 같은 우선순위인 자동 시작 태스크들 사이의 활성화 순서는 정의되어 있지 않다.
종료는 ShutdownOS 서비스로 이뤄지며 응용이 요청할 수도 있고 치명적 오류 때문에 운영체제가 요청할 수도 있다. 이 서비스가 불리면 운영체제는 ShutdownHook을 부른 뒤 종료한다. 사용자는 대개 ShutdownHook의 거동을 자유롭게 정할 수 있고, 루틴에서 돌아오지 않도록 만들어도 된다.
기동 훅과 인터럽트
StartupHook이 도는 동안 사용자 인터럽트는 모두 비활성이다. 범주 2 인터럽트는 스케줄러가 시작되는 마지막 단계에 이르기 전까지 돌 수 없다.[1]
오류 처리
규격은 오류를 둘로 나눈다. 응용 오류는 운영체제가 요청받은 서비스를 올바로 수행하지 못했지만 자기 내부 데이터의 정합성은 여전히 가정할 수 있는 경우다. 이때는 중앙집중식 오류 처리가 불리고, 분산 처리를 위해 상태 정보로도 오류가 반환된다. 치명적 오류는 운영체제가 내부 데이터의 정합성을 더는 가정할 수 없는 경우이며, 이때는 중앙집중식 시스템 종료가 불린다.[1]
ErrorHook은 시스템 서비스가 E_OK가 아닌 상태값을 반환할 때 불린다. ErrorHook 안에서 부른 시스템 서비스가 실패해도 훅이 다시 불리지는 않으므로 — 오류 훅의 재귀 호출은 일어나지 않는다 — 그 안에서 생긴 오류는 반환값을 확인해서만 감지할 수 있다. 알람 만료나 메시지 도착에 따른 태스크 활성화·이벤트 설정에서 오류가 감지될 때도 이 훅이 불린다.
효과적인 오류 관리를 위해 훅 안에서 추가 정보에 접근할 수 있다. OSErrorGetServiceId 매크로는 오류가 발생한 서비스의 식별자를 돌려주며 구현이 반드시 제공해야 한다. 문제가 된 서비스의 인자에 접근하는 매크로는 서비스 이름과 규격상의 인자 이름을 이어 붙이는 규칙으로 이름 지어진다 — 상대 알람 설정 서비스의 첫 인자에 접근하는 매크로는 OSError_SetRelAlarm_AlarmID가 된다. 첫 인자가 객체 식별자인 경우 그 접근 매크로의 제공은 필수이고, 최적화를 위해 구성 파일에서 매크로 접근을 끌 수 있다.
오류 검사에는 두 수준이 있다. standard status는 디버깅이 끝난 응용을 전제로 최소한의 상태만 돌려주고, extended status는 아직 완전히 디버깅되지 않은 응용의 시험을 돕도록 검사를 넓힌다. 어느 수준을 쓸지는 구성 언어의 상태 속성으로 정하며 자동 배정은 지원되지 않는다.[2]