HWPORT operating system
- 개발자
- 기록사항
2010년 1월 12일 : 구체적인 설계안 정리 시작
시작하기전에
이 프로젝트는 1996년부터 계획하였고 관련된 기술을 검토하는데에만 벌써 10년이 넘었습니다. 다소 느긋한 계획을 수립하였기에 많은 준비를 할수 있었습니다.
이제 본격적으로 관련된 사항을 정리하는 과정에 들어섰습니다. 구현은 이미 수차례 각각의 기술적 검토를 위해서 시도되었고 이것은 다시 설계안에 맞춰서 재작성 및 개선될 것입니다.
언제 이 프로젝트 완료할수 있을지는 모르겠으나 깊은 설계와 상상이 더해져서 멋진 무언가가 나올거라고 생각합니다.
설계
아직 목차 정리 고민중 .. . . .
타입 정리
코딩규칙 정리
NameSpace 정리
커널개념정리
파일시스템의 추가속성
그래픽 시스템
CUI와 GUI의 혼합 인터페이스
burst 속성의 API 실행 개념
새로운 패러다임에 대한 대응정리
컴파일러 설계
쉘의 확장개념
Posix 호환
- 3 level 특권 설계
- 아키텍쳐간 binary 레벨의 호환에 대한 아이디어 정리
- 메모리 관리 방법 정리
- 런타임 라이브러리 과 커널과의 관계 정리
- Frame buffer 장치 인스턴스
- Direct Window Manager
- Middle Window Manager
프로그래밍 언어 표준준수 기준 정의
- def_hwport_stdc : ANSI-C 를 준수하는 컴파일러인 경우
- def_hwport_stdc_version : ANSI-C 버젼번호 (long type)
#if defined(__STDC__) # define def_hwport_stdc (__STDC__) #else # undef def_hwport_stdc #endif #if defined(__STDC_VERSION__) # define def_hwport_stdc_version (__STDC_VERSION__) #else # undef def_hwport_stdc_version #endif #if defined(def_hwport_stdc) && (!defined(def_hwport_stdc_version)) # if defined(__STRICT_ANSI__) # define def_hwport_stdc_version (199001L) # else # define def_hwport_stdc_version (198901L) # endif #endif
컴파일러의 지원언어
- def_hwport_c : C 컴파일러 (C++컴파일러인 경우도 정의합니다. 추후 자체 컴파일러의 예외상황문법에 대응하기 위한 부부에 이것이 사용될 예정)
- def_hwport_cplusplus : C++컴파일러
#if !defined(def_hwport_c) # define def_hwport_c (1L) #endif #if defined(__cplusplus) # define def_hwport_cplusplus (1L) #else # undef def_hwport_cplusplus #endif
컴파일러 제품군
- def_hwport_turboc
- def_hwport_turboc_version
- def_hwport_gnuc
- def_hwport_gnuc_version
- def_hwport_msc
- def_hwport_msc_version
- def_hwport_icl
- def_hwport_icl_version
- def_hwport_watcomc
- def_hwport_watcomc_version
- def_hwport_borlandc
- def_hwport_borlandc_version
- def_hwport_hwportc
- def_hwport_hwportc_version
#if defined(__TURBOC__) # define def_hwport_turboc (1L) # define def_hwport_turboc_version (0x00200000 #else # undef def_hwport_turboc # undef def_hwport_turboc_version #endif ...
모듈간 흐름제약
- 모듈간에 상호 Atomic 처리를 위한 부분이 필요하기 때문에 되도록이면 모듈간 교착호출상태를 만들지 않도록 설계해야 하며 모듈은 각각 단방향성 호출로 설계를 고려할 필요가 있습니다.
- 하나의 모듈이 다른 모듈을 호출하게 되는 경우 호출하는 쪽은 Up module로 정의하고 호출되는쪽은 Down module로 정의합니다. 이렇게 다방향성 호출이 결정되면 Down module은 Up module을 호출하는것은 되도록이면 발생하지 않도록 작성되어야 합니다.
- 모든 callback함수는 그 callback 함수의 실행시간이 최대한 빠른시간내에 처리완료되도록 구성되거나 외부의 다른 task에서 처리되도록 최대한 callback에서의 지연을 방지하도록 설계되어야만 합니다. 하지만 커널에서는 두가지 callback을 제공할수 있으며 하나는 일반적인 callback이고 다른 하나는 async callback을 제공할수 있게 될것입니다.
- callback이 등록되었다면 해당 모듈의 close함수가 호출되기 전에 우선 callback에 대한 stop처리가 된후에 close되도록 작성되어야 합니다. 이것은 예기치 않은 제 3의 callback 호출처리도중에 close가 호출되는것을 원천적으로 막기위한 방법을 제시하도록 커널이 구성되어야 할 필요가 있기 때문입니다.
Wrapper 설계
- 커널에 기본은 적절한 유지보수관점에서 필요하나고 생각되는 모든 Wrapper 를 만들어 제공합니다.
- Wrapper는 하나의 interface역할을 수행하며 각 interface계층중에 하나를 선택했다면 해당 모듈은 되도록이면 선택한 interface계층에 대응하는 계층만 사용하도록 유도되어 설계되어야 합니다.
- Interface계층은 크게 index, virtual pointer, struct로 가르키는 handle의 3가지 계층이 지원되도록 노력해야 하며 handle이 없는 interface는 예외적용에 해당하고 되도록이면 handle없는 interface는 설계하지 않습니다.