TCRP (for Friend) 및 ARPL ...

로더의 안정성과 드라이버에 대한 부분에 대해서는 저는 생각이 조금 다릅니다.

 

기존 DSM6 시절에 사용했던 Jun 로더의 드라이버도 모든 드라이버가 포함되어 있던 통합팩이였습니다.

 

당시 헤놀로지 로더는 Jun 로더 하나뿐이였기에 선택지가 없었지만, 상당히 안정적인 로더 였습니다.

 

통합된 드라이버가 모두 들어가 있다고 해서 안정적인 요소를 해칠수는 없다고 봅니다.

 

 

 

M SHELL for TCRP가 드라이버를 로딩하는 과정을 설명드리자면,

 

https://github.com/PeterSuh-Q3/rp-ext/blob/main/all-modules/src/check-all-modules.sh

 

DSM 설치과정의 시작 (JUNIOR 모드) 부분에서

 

1. 플랫폼별 (지금까지 총 8가지) 모든 드라이버 ko 파일을 하나의 tgz 압축파일로 로더가 보관하고 있다가 Junior 과정에서

 

/lib/modules 에 압축을 해제합니다. 이 과정은 단순 파일복사에 해당합니다.

 

2. 새로 복사된 ko 드라이버의 모듈의존성을 재성하기 위해 depmod -a 를 사용합니다.

 

모듈간 의존성 까지 고려해서 설치 가능한 드라이버(모듈)을 새롭게 리스트업 하는 과정입니다.

 

3. 기존 TCRP 로더를 빌드 하는 과정에서 사용되는 필요 드라이버 자동감지 ( listpci 함수 ) 를 중지하고

 

대신 JUNIOR 모드와 DSM 부팅과정에서 대신 자동감지 합니다.

 

자동감지후 필요한 드라이버만 modprobe 로 드라이버를 주입합니다.

 

insmod 에 비해 modprobe가 드라이버간의 종속성까지 고려해서 더 안전한 설치를 진행합니다.

 

 

 

드라이버가 시스템의 안정성을 해칠수 있는 부분은

 

리눅스 커널 버전별로 새로 컴파일되서 개발되는 드라이버 자체의 안정성이 아닐까 싶습니다.

 

pocopico님이 레드필 드라이버의 대부분을 개발해 주고 계시지만,

 

불안정하게 컴파일된 드라이버도 간혹 존재합니다.

 

깃헙이나 헤놀포럼에 버그리포트가 되면 재컴패일해서 새로 제작도 해주시구요,

 

ARPL 의 fabio님도 새로 설계된 ARPL을 위해 pocopico님의 드라이버 소스를 참조해서

 

ARPL 용으로 다시 컴파일해서 통합드라이팩(모듈)을 사용하는데 새로 컴파일된 각 드라이버 하나하나의 안정성은

 

유저들에 의해 피드백 받는걸로 계속 보완하고 있지 않나 싶습니다.

 

 

 

pocopico님, fabio님과 여러번의 대화를 통해 새롭게 진행되고 있는 상황에 대에 논의를 하고 있습니다.

 

ARPL은 기존의 TT그룹(TTG)에서 최초 설계한 레드필의 엄격한 제한성을 탈피해서 새롭게 재설계가된 로더 입니다.

 

이 재설계과정에서 중요한 제한성을 무시한 부분이 커널패닉(KP)등을 유발하는 불안정 요소를 유발한것이 아닌가 싶습니다.

 

TCRP의 pocopico님도 현재 차세대 TCRP를 재설계해서 새로운 로더를 제작중에 있습니다.

 

이 엄격한 TTG 의 설계방식이 사용자 편의성을 저해하는 요소와 상충되기에 이부분에서 개발자들의 고민이 많은것 같습니다.

 

지금도 사용자의 편리성과 안정성 두마리 토끼를 잡기위해 노력하시는 개발자 분들의 노고에 감사를 드립니다.