Linux 커널의 소스 코드는 /usr/src/linux 디렉터리에 있습니다. 커널 소스 코드의 구성은 다음과 같습니다. 1. 핵심 소스 코드에서 지원하는 하드웨어 아키텍처와 관련된 핵심 코드가 포함된 아치 디렉터리 2. 대부분의 핵심 포함 파일이 포함된 포함 디렉터리 4. mm 디렉터리에는 모든 메모리 관리 코드가 포함되어 있습니다. 5. drivers 디렉터리에는 시스템의 모든 장치 드라이버가 포함되어 있습니다. 6. Ipc 디렉터리에는 핵심 프로세스 간 통신 코드가 포함되어 있습니다.
이 튜토리얼의 운영 환경: linux7.3 시스템, Dell G3 컴퓨터.
리눅스 커널 소스코드는 어디에 있나요?
리눅스 커널 소스코드는 다양한 방법으로 얻을 수 있습니다. 일반적으로 설치된 Linux 시스템에서 /usr/src/linux 디렉토리의 내용은 커널 소스 코드입니다.
소스 코드 읽기를 보다 원활하게 진행하려면 소스 코드 지식 배경을 미리 어느 정도 이해하고 있는 것이 가장 좋습니다.
Linux 커널 소스 코드의 구성은 다음과 같습니다(Linux 디렉터리를 기준으로 가정).
arch
이 하위 디렉터리에는 이 핵심 소스 코드에서 지원하는 하드웨어 아키텍처와 관련된 핵심 코드가 포함되어 있습니다. . 예를 들어 X86 플랫폼의 경우 i386입니다.
include
이 디렉터리에는 대부분의 핵심 포함 파일이 포함되어 있습니다. 지원되는 각 아키텍처에 대한 하위 디렉터리도 있습니다.
init
이 디렉토리에는 핵심 시작 코드가 포함되어 있습니다.
mm
이 디렉토리에는 모든 메모리 관리 코드가 포함되어 있습니다. 특정 하드웨어 아키텍처와 관련된 메모리 관리 코드는 Arch/*/mm 디렉터리에 있습니다. 예를 들어 X86에 해당하는 코드는 Arch/i386/mm/fault.c입니다.
drivers
시스템의 모든 장치 드라이버는 이 디렉토리에 있습니다. 이는 여러 유형의 장치 드라이버로 더 나뉘며, 각 드라이버에는 drivers/sound에 해당하는 사운드 카드 드라이버와 같은 해당 하위 디렉터리도 있습니다.
Ipc
이 디렉터리에는 핵심 프로세스 간 통신 코드가 포함되어 있습니다.
modules
이 디렉터리에는 빌드되었으며 동적으로 로드할 수 있는 모듈이 포함되어 있습니다.
fs Linux
지원되는 파일 시스템 코드. 서로 다른 파일 시스템에는 서로 대응하는 서로 다른 하위 디렉터리가 있습니다. 예를 들어, ext2 파일 시스템은 ext2 하위 디렉터리에 해당합니다.
Kernel
메인 코어 코드. 동시에 프로세서 구조와 관련된 코드는 arch/*/kernel 디렉토리에 배치됩니다.
Net
핵심 네트워크 부분 코드입니다. 내부의 각 하위 디렉터리는 네트워크의 한 측면에 해당합니다.
Lib
이 디렉토리에는 핵심 라이브러리 코드가 포함되어 있습니다. 프로세서 아키텍처와 관련된 라이브러리 코드는 arch/*/lib/ 디렉터리에 있습니다.
Scripts
이 디렉터리에는 코어를 구성하는 데 사용되는 스크립트 파일이 포함되어 있습니다.
Documentation
이 디렉토리는 참고용 문서입니다.
Linux를 분석하고 운영체제의 본질을 이해하고 싶다면 커널 소스 코드를 읽는 것이 가장 효과적인 방법입니다. . 좋은 프로그래머가 되려면 많은 연습과 코드 작성이 필요하다는 것을 우리 모두 알고 있습니다. 프로그래밍은 중요하지만, 프로그래밍만 하는 사람들은 쉽게 자신의 지식 영역으로 자신을 제한할 수 있습니다. 지식의 폭을 넓히려면 다른 사람이 작성한 코드, 특히 우리보다 더 발전된 사람들이 작성한 코드를 더 많이 접해야 합니다. 이러한 접근 방식을 통해 우리는 자신의 지식 서클의 제약에서 벗어나 다른 사람의 지식 서클에 들어갈 수 있으며 일반적으로 단기간에 배울 수 없는 정보에 대해 더 많이 배울 수 있습니다. Linux 커널은 오픈 소스 커뮤니티의 수많은 "마스터"에 의해 신중하게 유지 관리되며 이러한 사람들은 모두 최고의 코드 마스터라고 불릴 수 있습니다. 리눅스 커널 코드를 읽음으로써 우리는 커널 관련 지식을 배울 수 있을 뿐만 아니라, 그들의 프로그래밍 기술과 컴퓨터에 대한 이해를 배우고 이해하는 것이 더 가치 있다고 생각합니다.
저도 프로젝트를 통해 리눅스 커널 소스코드 분석을 접하게 되었고, 소스코드 분석 작업을 하면서 많은 유익을 얻었습니다. 관련 커널 지식을 얻는 것 외에도 커널 코드에 대한 나의 과거 이해도 바뀌었습니다.
1. 커널 소스 코드 분석은 "손이 닿지 않는" 것이 아닙니다. 커널 소스 코드 분석의 어려움은 소스 코드 자체에 있는 것이 아니라, 코드를 분석하기 위해 보다 적절한 방법과 수단을 사용하는 방법에 있습니다. 커널의 거대함은 일반적인 데모 프로그램처럼 주요 기능부터 시작하여 단계별로 커널 소스 코드를 분석할 수 없다는 것을 의미합니다. 이 "요청 시 요청" 접근 방식을 사용하면 특정 세부 사항에 너무 집착하지 않고 소스 코드의 주요 라인을 파악할 수 있습니다.
2. 코어 디자인이 이쁘네요. 커널의 특정 상태는 커널의 실행 효율성이 현재 컴퓨터 응용 프로그램의 실시간 요구 사항에 대응할 만큼 높아야 함을 결정합니다. 이러한 이유로 Linux 커널은 C 언어와 어셈블리의 하이브리드 프로그래밍을 사용합니다. 그러나 우리 모두는 소프트웨어 실행 효율성과 소프트웨어 유지 관리성이 많은 경우 서로 상충된다는 것을 알고 있습니다. 커널의 효율성을 보장하면서 커널의 유지 관리성을 향상시키는 방법은 커널의 "아름다운" 디자인에 달려 있습니다.
3． 놀라운 프로그래밍 기술. 일반 응용 소프트웨어 설계 분야에서는 개발자들이 소프트웨어의 좋은 설계에 더 많은 관심을 기울이고 코딩은 단지 구현 수단의 문제일 뿐이므로 코딩의 상태는 아무리 강조해도 지나치지 않을 수 있습니다. 생각이 너무 많아요. 그러나 커널에서는 그렇지 않습니다. 좋은 코딩 디자인은 유지 관리성을 향상시킬 뿐만 아니라 코드 성능도 향상시킵니다.
커널에 대한 이해는 사람마다 다를 것입니다. 커널에 대한 이해가 깊어질수록 우리는 커널의 설계와 구현에 대해 더 많은 생각과 경험을 갖게 될 것입니다. 따라서 이 글은 리눅스 커널의 문 밖에서 방황하는 더 많은 사람들이 리눅스의 세계로 들어가 커널의 마법과 위대함을 스스로 경험할 수 있도록 안내하기를 바랍니다. 그리고 나는 커널 소스 코드의 전문가는 아니지만 소스 코드 분석에 대한 내 자신의 경험과 경험을 공유하고 이를 필요로 하는 사람들에게 참조와 도움을 제공하고 싶습니다. 특히 컴퓨터 업계에서는 운영 체제 커널에 대한 적당한 노력을 기울였습니다. 더 이상 고민하지 않고(이미 너무 길어졌습니다. 죄송합니다~) 저만의 Linux 커널 소스 코드 분석 방법을 공유하겠습니다.
사람이 새로운 것을 이해하는 관점에서 볼 때, 사물의 본질을 탐구하기 전에 새로운 것을 이해하는 과정이 있어야 합니다. 새로운 것을 이해합니다. 예비 개념을 생성합니다. 예를 들어, 피아노를 배우려면 먼저 피아노를 연주하려면 기본 음악 이론, 단순화된 기보법, 오선보 및 기타 기본 지식을 배워야 한다는 점을 이해한 다음 피아노 연주 기술과 운지법을 배우고 마지막으로 실제로 시작할 수 있습니다. 피아노 연습.
커널 코드를 분석할 때도 마찬가지입니다. 먼저 분석할 코드에 포함된 내용을 찾아야 합니다. 프로세스 동기화 및 스케줄링을 위한 코드인가, 메모리 관리를 위한 코드인가, 장치 관리를 위한 코드인가, 시스템 시동을 위한 코드인가. 커널의 크기가 크기 때문에 모든 커널 코드를 한 번에 분석할 수는 없으므로 합리적인 작업 분담이 필요합니다. 알고리즘 설계에서 알 수 있듯이 큰 문제를 해결하려면 먼저 관련된 하위 문제를 해결해야 합니다.
분석할 코드 범위를 찾은 후에는 모든 리소스를 사용하여 코드의 이 부분의 전반적인 구조와 일반적인 기능을 최대한 포괄적으로 이해할 수 있습니다.
여기에 언급된 모든 리소스는 Baidu, Google의 대규모 온라인 검색 엔진, 운영 체제 원리 교과서 및 전문 서적, 또는 다른 사람이 제공한 경험과 정보 또는 심지어 제공되는 Linux 소스 코드를 참조합니다. 문서, 의견 및 소스 코드 식별자의 이름(코드의 식별자 이름을 과소평가하지 마십시오. 때로는 핵심 정보를 제공할 수도 있습니다). 간단히 말해서, 여기에 있는 모든 리소스는 여러분이 생각할 수 있는 모든 사용 가능한 리소스를 의미합니다. 물론, 이러한 형태의 정보 수집을 통해 우리가 원하는 모든 정보를 얻는 것은 불가능합니다. 정보가 더 포괄적으로 수집될수록 후속 코드 분석 프로세스에서 더 많은 정보를 사용할 수 있고 분석 프로세스가 덜 어려워집니다.
다음은 Linux 주파수 변환 메커니즘으로 구현된 코드를 분석한다고 가정하는 간단한 예입니다. 지금까지 우리는 이 용어를 문자 그대로의 의미로만 보면 CPU의 주파수 조정과 관련이 있다고 대략적으로 추측할 수 있습니다. 정보 수집을 통해 우리는 다음과 같은 관련 정보를 얻을 수 있어야 합니다:
1. CPUFreq 메커니즘.
2. 성능, 절전, 사용자 공간, 주문형, 보수적인 주파수 조절 전략.
3． /드라이버/cpufreq/.
4． /문서/cpufreq.
5． P 상태와 C 상태.
Linux 커널 코드를 분석할 때 이 정보를 수집할 수 있다면 매우 "운이 좋다"는 것입니다. 결국 Linux 커널에 대한 정보는 .NET이나 JQuery만큼 풍부하지는 않습니다. 그러나 강력한 검색 엔진도 없고 관련 연구 자료도 없었던 10년 전과 비교하면 "위대한" 커널이라고 불러야 합니다. 수확'시대! 간단한 "검색"(1~2일이 소요될 수 있음)을 통해 우리는 코드의 이 부분이 있는 소스 코드 파일 디렉터리까지 찾았습니다. 이런 종류의 정보는 그야말로 "귀중한" 것입니다!
데이터 수집에서 소스 코드와 관련된 소스 코드 디렉터리를 "운이 좋게" 찾았습니다. 하지만 이것이 우리가 실제로 이 디렉터리의 소스 코드를 분석하고 있다는 의미는 아닙니다. 때로는 우리가 찾는 디렉토리가 흩어져 있을 수도 있고, 때로는 우리가 찾는 디렉토리에 특정 기계와 관련된 코드가 많이 포함되어 있을 수도 있으며, 우리는 기계와 관련된 특수 코드보다는 분석 대상 코드의 주요 메커니즘에 더 관심을 갖습니다( 이는 커널의 특성을 더 잘 이해하는 데 도움이 됩니다. 따라서 정보 중 코드 파일이 포함된 정보를 신중하게 선택해야 합니다. 물론 이 단계는 한 번에 완료될 가능성이 낮으며 분석할 모든 소스 코드 파일을 한 번에 선택할 수 있고 그 중 하나도 누락되지 않을 것이라고 누구도 보장할 수 없습니다. 하지만 대부분의 모듈과 관련된 핵심 소스 파일을 캡처할 수 있다면 나중에 코드를 자세히 분석하면 자연스럽게 모두 찾을 수 있으므로 걱정할 필요가 없습니다.
위의 예로 돌아가서 /documention/cpufreq 아래의 문서를 주의 깊게 읽어보세요. 현재 리눅스 소스코드는 소스코드 디렉토리의 Documentation 폴더에 해당 모듈과 관련된 문서를 저장하게 되는데, 분석 대상 모듈에 문서가 없으면 핵심 소스코드 파일을 찾기가 다소 어려워지지만, 우리가 분석하려는 소스 코드를 찾을 수 없게 되는 것은 아닙니다. 문서를 읽으면 최소한 소스 파일 /driver/cpufreq/cpufreq.c에 주의를 기울일 수 있습니다. 이전에 수집된 주파수 변조 전략과 결합된 이 소스 파일 문서를 통해 우리는 5개의 소스 파일 cpufreq_performance.c, cpufreq_powersave.c, cpufreq_userspace.c, cpufreq_ondemand 및 cpufreq_conservative.c에 쉽게 주의를 기울일 수 있습니다. 관련 문서는 모두 찾았나요? 걱정하지 마세요. 분석을 시작하면 조만간 다른 소스 파일을 찾을 수 있을 것입니다. Windows에서 sourceinsight를 사용하여 커널 소스 코드를 읽으면 코드 분석과 결합된 함수 호출 및 기호 참조 검색과 같은 기능을 통해 freq_table.c, cpufreq_stats.c 및 /include/linux/cpufreq 다른 파일을 쉽게 찾을 수 있습니다. 시간.
검색된 정보 흐름 방향에 따라 분석해야 할 소스 코드 파일을 완벽하게 찾을 수 있습니다. 소스 코드를 찾는 단계는 그다지 중요하지 않습니다. 모든 소스 코드 파일을 찾을 필요가 없고 작업의 일부를 코드 분석 프로세스로 미룰 수 있기 때문입니다. 소스 코드 위치 지정도 소스 코드 파일의 일부를 찾는 것이 소스 코드 분석의 기초입니다.
Simple Comments
찾은 소스 코드 파일에서 각 변수, 매크로, 함수, 구조 및 기타 코드 요소의 일반적인 의미와 기능을 분석합니다. 이것을 단순 주석이라고 부르는 이유는 이 부분의 주석 작업이 매우 단순하다는 뜻이 아니라, 이 부분의 주석이 해당 주석의 의미를 대략적으로 설명하는 한, 너무 자세할 필요는 없다는 뜻입니다. 관련 코드 요소. 오히려 여기서의 작업은 실제로 전체 분석 과정에서 가장 어려운 단계입니다. 커널 코드에 대해 깊이 파고드는 것이 처음이기 때문에, 특히 커널 소스 코드를 처음 분석하는 분들에게는 생소한 GNU C 구문과 압도적인 매크로 정의가 너무 많아서 매우 실망스러울 것입니다. 이때, 진정하고 각각의 주요 어려움을 이해하는 한, 앞으로 비슷한 어려움에 직면할 때 함정에 빠지지 않도록 할 수 있습니다. 게다가 커널과 관련된 다른 지식도 나무처럼 계속해서 확장될 것입니다.
예를 들어 "DEFINE_PER_CPU" 매크로의 사용은 cpufreq.c 파일 시작 부분에 표시됩니다. 정보를 참조하면 기본적으로 이 매크로의 의미와 기능을 이해할 수 있습니다. 여기서 사용하는 방법은 기본적으로 이전에 데이터를 수집할 때 사용했던 방법과 동일합니다. 또한 sourceinsight에서 제공하는 정의로 이동 기능을 사용하여 해당 정의를 보거나 LKML(Linux Kernel Mail List)을 사용하여 볼 수도 있습니다. 간단히 말해서, 가능한 모든 수단을 사용하면 항상 이 매크로의 의미를 얻을 수 있습니다. 즉, 각 CPU에 대해 독립적으로 사용되는 변수를 정의할 수 있습니다.
우리는 코멘트를 한 번에 정확하게 기술할 것을 고집하지 않고(각 기능의 구체적인 구현 과정을 파악할 필요도 없고, 일반적인 기능적 의미만 파악하면 됩니다), 수집된 정보와 다음 사항을 결합합니다. code 분석을 통해 주석의 의미가 지속적으로 향상됩니다(여기서는 원본 주석과 소스 코드의 식별자 이름이 매우 유용합니다). 지속적인 주석, 정보에 대한 지속적인 참조, 주석의 의미에 대한 지속적인 수정을 통해.
관련된 모든 소스 코드 파일에 간단히 주석을 달면 다음과 같은 결과를 얻을 수 있습니다.
1. 기본적으로 소스 코드의 코드 요소의 의미를 이해합니다.
2. 기본적으로 이 모듈과 관련된 주요 소스코드 파일은 모두 찾았습니다.
이전에 수집된 정보와 데이터를 기반으로 분석 대상 코드의 전체적 또는 아키텍처적 설명과 결합하여 분석 결과를 데이터와 비교하여 코드에 대한 이해를 판단하고 수정할 수 있습니다. 이렇게 간단한 코멘트를 통해 소스코드 모듈의 주요 구조를 전체적으로 파악할 수 있습니다. 이는 또한 간단한 주석의 기본 목적을 달성합니다.
코드의 간단한 코멘트를 완성하고 나면 모듈 분석이 반쯤 끝났고, 남은 내용은 코드에 대한 심층적인 분석과 철저한 이해라고 볼 수 있습니다. 간단한 주석은 코드 요소의 특정 의미를 항상 매우 정확하게 설명할 수 없으므로 자세한 주석이 매우 필요합니다. 이 단계에서는 다음 사항을 명확히 해야 합니다.
1. 변수 정의가 사용되는 경우.
2. 매크로에 의해 정의된 코드가 사용되는 경우.
3． 함수 매개변수와 반환값의 의미.
4． 함수의 실행 흐름과 호출 관계.
5． 구조 필드의 구체적인 의미와 사용 조건.
함수 외부의 코드 요소의 의미는 기본적으로 간단한 주석으로 명확하기 때문에 이 단계를 세부 함수 주석이라고 부를 수도 있습니다. 함수 자체의 실행 흐름과 알고리즘이 주석 및 분석 부분의 주요 작업입니다.
예를 들어, (dbs_check_cpu 함수에서) cpufreq_ondemand 정책의 구현 알고리즘이 구현되는 방법입니다. 알고리즘의 내용을 이해하기 위해서는 함수에서 사용하는 변수와 호출되는 함수를 점진적으로 분석해야 합니다. 최상의 결과를 얻으려면 가장 직관적인 표현 방법인 이러한 복잡한 함수의 실행 흐름도와 함수 호출 관계 다이어그램이 필요합니다.
이 단계의 주석을 통해 기본적으로 분석할 코드의 전반적인 구현 메커니즘을 완벽하게 파악할 수 있습니다. 모든 분석 작업은 80% 완료된 것으로 간주됩니다. 이 단계는 특히 분석할 코드의 내부 모듈 구분을 더 잘 이해할 수 있을 만큼 정확한 주석 정보를 작성하도록 노력해야 합니다. Linux 커널은 매크로 구문 "module_init" 및 "module_exit"를 사용하여 모듈 파일을 선언하지만, 모듈 내의 하위 기능 구분은 모듈 기능에 대한 완전한 이해를 기반으로 합니다. 모듈을 올바르게 분할해야만 모듈이 제공하는 외부 기능과 변수가 무엇인지 파악할 수 있습니다(EXPORT_SYMBOL_GPL 또는 EXPORT_SYMBOL로 내보낸 기호를 사용하여). 그래야만 모듈 내의 식별자 종속성을 분석하는 다음 단계로 진행할 수 있습니다.
네 번째 단계에서 코드 모듈을 나누어 모듈을 하나씩 "쉽게" 분석할 수 있습니다. 일반적으로 파일 하단에 있는 모듈 진입 및 종료 함수("module_init" 및 "module_exit"에 의해 선언된 함수는 일반적으로 파일 끝에 있음)에서 시작할 수 있습니다. 우리 자신 또는 다른 모듈) 및 사용된 함수 주요 변수(이 파일의 전역 변수 또는 다른 모듈의 외부 변수)는 "함수-변수-함수" 종속성 다이어그램을 그립니다. 이를 식별자 종속성 다이어그램이라고 부릅니다.
물론, 모듈 내의 식별자 종속 관계는 단순한 트리 구조가 아니지만, 많은 경우 복잡한 네트워크 관계입니다. 이때 코드에 대한 자세한 설명의 역할이 반영됩니다. 모듈을 함수 자체의 의미에 따라 하위 함수로 나누고 각 하위 함수의 식별자 종속성 트리를 추출합니다.
식별자 종속성 분석을 통해 모듈에서 정의한 함수가 어떤 함수를 호출하는지, 어떤 변수가 사용되는지, 모듈 하위 함수 간의 종속성을 명확하게 보여줄 수 있습니다. 어떤 함수와 변수가 공유되는지 등
모듈 간 상호의존성
모든 모듈 내부 식별자 종속성 다이어그램을 정리하면 해당 모듈 종속성이 사용하는 다른 모듈의 변수나 함수를 기반으로 쉽게 얻을 수 있습니다.
cpufreq 코드 모듈 종속 관계는 다음과 같은 관계로 표현될 수 있습니다.
모듈 간 종속성 다이어그램을 통해 분석 대상 코드 전체에서 모듈의 상태와 기능을 명확하게 표현할 수 있습니다. 이를 바탕으로 모듈을 분류하고 코드의 구조적 관계를 정리할 수 있습니다.
cpufreq의 모듈 종속성 다이어그램에서 볼 수 있듯이 모든 주파수 변조 전략 모듈은 핵심 모듈 cpufreq, cpufreq_stats 및 freq_table에 종속되어 있음을 명확하게 볼 수 있습니다. 세 가지 종속 모듈을 코드의 핵심 프레임워크로 추상화하면 이러한 주파수 변조 전략 모듈은 이 프레임워크를 기반으로 구축되며 사용자 계층과의 상호 작용을 담당합니다. 핵심 모듈 cpufreq는 기본 시스템과의 상호 작용을 담당하는 드라이버 및 기타 관련 인터페이스를 제공합니다. 따라서 다음과 같은 모듈 아키텍처 다이어그램을 얻을 수 있습니다.
물론, 아키텍처 다이어그램은 모듈의 무기적 접합이 아닙니다. 또한 우리가 참조한 정보를 기반으로 아키텍처 다이어그램의 의미를 풍부하게 해야 합니다. 따라서 여기에 있는 아키텍처 다이어그램의 세부 사항은 사람들의 이해에 따라 달라질 수 있습니다. 하지만 아키텍처 다이어그램 본문의 의미는 기본적으로 동일합니다. 이 시점에서 분석할 커널 코드에 대한 모든 분석을 완료했습니다.
관련 추천: "Linux 비디오 튜토리얼"
위 내용은 Linux 커널의 소스 코드는 어느 파일에 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![Linux 운영 및 유지보수 기본과정 [전체 과정에 대한 자세한 설명]](https://img.php.cn/upload/course/000/000/068/63ff173c79edd672.jpg)
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
