Virtual Vector I/O
글쓴이: oprsystem / 작성시간: 토, 2004/02/07 - 9:03오전
안녕하세요.
RedBoot 를 분석중인데 Virtual Vector I/O TABLE에 의한 HAL(하드웨어 추상화 단계)의 연결 구현에 대해서 전혀 감이 안잡힙니다.
쉽게 떠오른 아이디어는 함수 포인터의 배열로 접근하는거 같은데, 아이디어만 떠오를뿐 구현원리는 전혀 몰라서 답답합니다.
아시는 분은 가르쳐 주시면 감사 드립니다.
Forums:
저두 2년전에 RedBoot 코드를 첨 보긴 했는데.. 비단 RedBoo
저두 2년전에 RedBoot 코드를 첨 보긴 했는데.. 비단 RedBoot뿐만 아니라 2개 이상의 CPU 아키텍쳐를 지원하는 대부분의 시스템 프로그램들은 유사한 형태의 HAL을 제공합니다.
일단 HAL이라는 개념에서 유추해 보시면 이해가 되시리라 생각이 드네요.
RedBoot의 고유기능 즉, 공통적이면서 하드웨어 플랫폼에 의존적이지 않은 코드들에 대해서 항상 동일한 환경을 제공하기 위해서 HAL이라는 추상화 레이어를 만들어서, 아래에 있는 하드웨어에 의존적인 코드들을 HAL로 숨기는 방식이죠.
Virtual Vector I/O도 이러한 일환으로, RedBoot의 하드웨어 독립적인 코드들은 Virtual Vector I/O table의 미리 정의된 공통된 형식(해당 IO블럭에 클래스,입력/출력/제어 함수 API를 미리 정의)으로 함수를 호출합니다. 물론 사전에 Virtual Vector I/O table에는 사용할 CPU 플랫폼에 맞는 하드웨어 의존코드로 짜인 함수들을 맵핑(사용할 IO구조체 등록) 시켜 두는 거죠.
이렇게 함으로써, 하드웨어 독립적인 코드와 하드웨어 의존적인 코드를 서로 분할 시켜서 관리할 수 있고, 하드웨어 독립적인 코드는 하드웨어 변경과는 상관없이 거의 대부분 재사용이 가능합니다.
하지만, 보다 많은 하드웨어 플랫폼을 제공하기 위해서 HAL이 더 복잡해지거나 예외상황이 발생하게 되기도 합니다. (^^)
답변 감사 드립니다.지금도 분석중입니다. 처음 질문을 올렸을때 처럼
답변 감사 드립니다.
지금도 분석중입니다. 처음 질문을 올렸을때 처럼 모르는 상태는 아니지만 macro 의 바다에서 헤엄치는 상태 입니다. 뭔가 확실한게 생기면 정리해 보겠습니다..
황혼보다 어두운 자여
내 몸에 흐르는 피보다 더 붉은 자여
시간의 흐름 속에 파뭍힌 위대한 그대의 이름을 걸고 나 여기서 어둠에 맹세하노라
우리 앞을 가로막고 있는 모든 어리석은 자 들에게
나와 그대의 힘을
위대한 파멸의 힘을 보여줄 것을
[code:1]#define CYGACC_CALL_IF_VERSION&#
이 define 문장에서 3번째 줄이 독립된 것인지 아니면 define 에 종속된건지 궁금합니다. 분명히 독립된거 같은데...
황혼보다 어두운 자여
내 몸에 흐르는 피보다 더 붉은 자여
시간의 흐름 속에 파뭍힌 위대한 그대의 이름을 걸고 나 여기서 어둠에 맹세하노라
우리 앞을 가로막고 있는 모든 어리석은 자 들에게
나와 그대의 힘을
위대한 파멸의 힘을 보여줄 것을
첫번째 줄과 두번째 줄 (연결되어있죠)은 CYGACC_CALL_IF_VE
첫번째 줄과 두번째 줄 (연결되어있죠)은 CYGACC_CALL_IF_VERSION이라는 매크로를 정의하는 부분인데, 이 부분은 함수 프로토타입만을 명시한 것입니다.
마지막 줄에 있는 것은 위에서 정의된 함수에 대한 inline함수 바디(body)를 지정한 것입니다. 헤더파일을 보시면 알겠지만, hal_virtual_vector_table에 등록되어 있는 함수포인터를 찾아서 해당 함수를 수행하게 되어 있습니다.
예제에서 CYGNUM_CALL_IF_VERSION은 0입니다. 즉, 함수테이블의 첫번째에 등록된 함수가 호출되겠죠....^^
여기에 함수포인터로 등록된 함수가 결국 architecture 의존적인 함수가 되겠죠... 하지만, 상위 코드들은 CYGACC_CALL_IF_VERSION() 매크로를 활용하기 때문에 하위코드와는 독립적인 구조가 되는거죠....
댓글 달기