커널2.6으로 업하고나서 튜..

더이상 MOD_INC_USE_COUNT 등의 매크로를 사용하지 않는 다고 하는 것을
읽었습니다. 2.6 커널에서 모듈 컴파일에 관해 번역한 문서가 있기는 한데...
짬짬히 하는 거라 영어 딸리면 대충하기도 하고 그래서리.. 쫌 올리기 그렇습니다. 암튼 간에 참조 하세요.

LWN 에 올라온 글을 번역해 놓은 건데 일부만 발췌해서 올립니다. 제가 번역하고 있는 부분을 다 하면, 전체를 올리던지 하겠습니다. (공식적으로 올리는 것은 메일도 보내서 허락도 받아야 할것도 같아서요. 죄송~ ^^)

The module use count

2.4와 그 이전의 커널들에서 모듈들은 그들의 "use count"를 MOD_INC_USE_COUNT와 같은 매크로를 사용하여 관리했다. 물론 사용수(use count)는 모듈이 사용중일때 언로드 되는 것을 방지하기 위한 것이다. 이 방법은 항상 약간의 에러를 유발하는 경향이 있으며, 특히 사용수가 모듈 자체에서 조작될 때 발생한다. 2.6 커널에서는 참조 값(reference count)은 다른 방식으로 다루어 진다.

모듈에 대한 참조값을 조작하는 유일하게 안전한 방법은 모듈코드의 밖에서 하는 것이다. 다른 말로 말하면, 커널이 모듈안에서 참조값이 0 인채로 항상 실행되고 있을 것이다. 따라서, 이 작업은 모듈의 바깥으로 옮겨 졌고, 모듈 작성자의 삶이 조금 쉬워 졌다.(역주:말 대빵이상하군요.. 허허..)

모듈 안으로 들어가거나 모듈의 자원을 사용하고자 하는 모든 코드들은 먼저 모듈의 참조값을 증가시키려는 시도를 반드시 해야한다:

int try_module_get(&module);

try_module_get()으로 부터 리턴되는 값을 보아야하는 것도 반드시 필요하다; 0 이 리턴되는 것은 시도가 실패했다는 것이고, 그 모듈은 사용될 수 없다. 예를 들어 모듈이 언로드되는 과정줄에 있을 때 실패가 일어날 수 있다.

모듈에 대한 참조는 module_put()으로 해제될 수 있다.

다시 말하지만, 모듈은 일반적으로 자신의 참조값을 조작해서는 안된다. 한 가지 예외를 들자면 만일 다른 곳에서 얻어질 수 없는 내부 데이터 구조 또는 함수를 참조하는 경우가 있다. 이 드문 경우에 모듈은 상상할 수 있듯이 try_module_get()을 스스로 호출할 수 있다.

이 글을 쓰는 시점에서 모듈은 초기화하는 동안 try_module_get()이 성공할 것이라는 의미로으로 살아있는(live) 것으로 간주된다. 모듈의 초기화 과정을 끝마치기 전까지 해당 모듈은 접근 불가능한 것과 같은 변경된 것들에 대해 이야기 할 것들이 있다. 그러한 변화는 모듈의 초기화 과정이 실패했을 때 경쟁조건(race condition)을 방지하는 것을 도와준다. 하지만, 그것은 또한 모듈이 빠르게 사용가능하도록 하는 데 어려움을 만든다. 예를 들어 블럭 드라이버들은 디스크들이 등록될때 파티션 테이블들을 읽을 수 있어야 하고 그러한 것은 보통 모듈이 자신을 초기화 할때 일어난다. 만일 정책이 변경된다면 모듈들은 초기화하는 동안의 제약이 없어지고, make_module_live()와 같은 함수의 호출은 그러한 모듈이 곧 사용가능 해지기 위해 요청될 것이다.(Update 2.6.0-test9: 이 변화는 일어나지 않았고 이 시점에서는 일어날 것 같지 않다.) (이 문단은 정말 알쏭달쏭하군요.. 음..)

마지막으로 드라이버 제작자가 모듈의 사용수를 0 으로 설정하는 특별한 ioctl() 함수를 넣는 것은 일반적인 일은 아니다. 간혹 모듈을 개발하는 동안 발생한 오류들은 커널로 하여금 모듈을 내려야할 수 밖에 없지만, 모듈의 참조값이 결코 0 이 될 수 없는 상태로 이르게 할 수 있다. 새로운 모듈 코드는 만일 CONFIG_MODULE_FORCE_UNLOAD 옵션이 설정되어 있다면, 특별한 참조값을 가지는 모듈을 강제 언로드 할 수 있도록 지원한다. 두말할 나위 없이, 이 옵션은 개발 시스템에서만 사용되어야 하고, 그 경우라도 매우 큰 주의를 요구한다.