Linux 커널 준비 작업 이해: C 언어 및 운영 체제에 대한 약간의 이해

머리말: 운영체제(영어: Operating System, 약어: OS)는 컴퓨터 하드웨어와 소프트웨어 자원을 관리하는 시스템 소프트웨어이며, 컴퓨터 시스템의 핵심이자 초석이기도 합니다. 운영체제는 비디오 메모리 관리 및 구성, 시스템 자원 수급 우선순위 결정, 입출력 장치 제어, 네트워크 운영, 파일 시스템 관리 등 기본적인 작업을 처리해야 한다. 운영 체제는 사용자가 시스템과 상호 작용할 수 있는 운영 인터페이스도 제공합니다.

1. 리눅스 커널 준비

Linux 커널 이해를 준비하기 위한 최고의 지식 포인트:

C 언어 이해하기

운영 체제에 대해 조금 알아보세요

소수 관련 알고리즘에 익숙함

컴퓨터 아키텍처 이해

Linux 커널 기능:

Linux 커널 작업:

1. 기술적인 관점에서 커널은 하드웨어와 소프트웨어 사이의 중간 계층입니다. 그 기능은 애플리케이션 계층 시퀀스 요청을 하드웨어에 전달하고 시스템의 다양한 장치와 구성 요소를 폴링하는 하위 수준 드라이버 역할을 하는 것입니다.

2. 애플리케이션 수준에서 애플리케이션은 하드웨어와 연결되지 않고 커널과만 연결됩니다. 커널은 애플리케이션이 아는 계층 중 가장 낮은 수준입니다. 실제 작업에서 커널은 관련 세부 사항을 구현합니다.

3. 커널은 리소스 관리 프로그램입니다. 다양한 시스템 프로세스에 사용 가능한 공유 리소스(CPU 시간, 디스크 공간, 네트워크 연결 등)를 할당하는 역할을 담당합니다.

4. 커널은 시스템 지향 명령 세트를 제공하는 라이브러리와 같습니다. 애플리케이션에서 시스템 호출은 일반 함수를 호출하는 것과 같습니다.

커널 구현 전략:

1.마이크로커널. 가장 기본적인 기능은 중앙 커널(마이크로커널)에 의해 구현됩니다. 다른 모든 기능은 잘 정의된 통신 소켓을 통해 중앙 코어와 통신하는 독립적인 프로세스에 위임됩니다.

2. 매크로 커널. 하위 시스템(예: 비디오 메모리 관리, 파일 관리, 장치 드라이버)을 포함한 커널의 모든 코드는 파일로 패키지됩니다. 커널의 모든 함수는 커널의 다른 모든 부분에 액세스할 수 있습니다. 현재 모듈의 동적 로드 및 언로드(절단)를 지원합니다. Linux 커널은 이 전략을 기반으로 구현됩니다.

커널 메커니즘은 어디에 사용되나요?

1. 프로세스 간 통신(주소 공간은 CPU의 가상 메모리에 할당되며 각 프로세스의 주소 공간은 완전히 독립적입니다. 동시에 실행되는 프로세스 수는 CPU 수를 초과하지 않습니다) 특정 커널 메커니즘을 사용합니다.

2. 프로세스 간 전환(동시에 실행되는 프로세스 수가 CPU 수를 초과하지 않음)에도 커널 메커니즘을 사용해야 합니다.

프로세스 전환도 FreeRTOS 작업 전환과 같은 상태를 저장하고 프로세스를 유휴 상태/재개 상태로 전환해야 합니다.

3. 프로세스 일정. 해당 프로세스가 실행된 기간을 확인합니다.

Linux 프로세스:

1. 계층 구조를 사용하면 각 프로세스는 상위 프로세스에 종속됩니다. 커널은 첫 번째 프로세스로 init 프로그램을 시작합니다. 이 프로세스는 추가 시스템 초기화 작업을 담당합니다. init 프로세스는 프로세스 트리의 루트이며 모든 프로세스는 이 프로세스에서 직접 또는 간접적으로 시작됩니다.

2. pstree 명령을 통해 쿼리합니다. 사실 시스템의 첫 번째 프로세스는 init가 아닌 systemd입니다(이것도 혼란스러운 지점입니다)

3. 시스템의 각 프로세스에는 고유한 식별자(ID)가 있으며, 사용자(또는 다른 프로세스)는 해당 ID를 사용하여 프로세스에 액세스할 수 있습니다.

두 번째, 리눅스 커널 소스코드의 디렉터리 구조

Linux 커널 소스 코드는 세 가지 주요 부분으로 구성됩니다.

1. 3장에서 설명하는 다양한 하위 시스템 및 하위 모듈과 전원 관리, Linux 초기화 등과 같은 기타 지원 하위 시스템을 포함한 커널 코어 코드

2. 라이브러리 파일(Linux 커널은 독립형 커널이므로, 즉 커널은 다른 소프트웨어에 의존하지 않고 자체적으로 컴파일될 수 있으므로), 펌웨어 컬렉션, KVM( 가상 머신 기술) 등

3. 스크립트, 구성 파일, 도움말 문서, 저작권 설명 및 기타 보조 파일을 컴파일하세요

ls 명령을 사용하여 커널 소스 코드의 최상층 디렉토리 구조를 들어보세요.

include/----커널 헤더 파일은 외부 모듈(예: 사용자 공간 코드)에 제공되어야 합니다. kernel/----섹션 3.2에 설명된 프로세스 스케줄링 하위 시스템 및 프로세스 스케줄링과 관련된 모듈을 포함하는 Linux 커널의 핵심 코드입니다. mm/----비디오 메모리 관리 하위 시스템(섹션 3.3). fs/----VFS 하위 시스템(섹션 3.4). net/----네트워크 장치 드라이버를 포함하지 않는 네트워크 하위 시스템입니다(섹션 3.5). ipc/----IPC(프로세스 간 통신) 하위 시스템입니다. arch//----arm, x86 등 아키텍처와 관련된 코드입니다. Arch//mach------특정 기계/보드 관련 코드입니다. Arch//include/asm----아키텍처 관련 헤더 파일입니다. Arch//boot/dts----DeviceTree 파일. init/----Linux 시스템 시작 초기화와 관련된 코드입니다. block/----블록 장치의 계층 구조를 제공합니다. sound/----오디오 관련 드라이버 및 하위 시스템은 "오디오 하위 시스템"으로 간주될 수 있습니다. drivers/----장치 드라이버(Linuxkernel3.10에서 장치 드라이버는 코드의 49.4%를 차지합니다). lib/----CRC, FIFO, 목록, MD5 등과 같이 커널에서 사용해야 하는 라이브러리 함수를 구현합니다. crypto/------암호화 및 복호화와 관련된 라이브러리 기능입니다. security/----보안 기능(SELinux)을 제공합니다. virt/----가상 머신 기술(KVM 등)에 대한 지원을 제공합니다. usr/----initramfs를 생성하는 데 사용되는 코드입니다. 펌웨어/----타사 장치를 구동하는 데 사용되는 펌웨어를 저장합니다. 샘플/----일부 샘플 코드입니다. tools/----성능 분석, 자체 테스트 등과 같은 몇 가지 일반적인 도구입니다. Kconfig, Kbuild, Makefile, scripts/----커널 컴파일에 사용되는 구성 파일, 스크립트 등. 복사 ----저작권 진술. 유지관리자----관리자 목록입니다. 크레딧----Linux의 주요 기여자 목록입니다. 보고-버그 ----버그 보고 매뉴얼. 문서, README----도움말, 문서.

[기사 특전] 편집자가 자신의 리눅스 커널 기술 교류 그룹을 추천합니다: [865977150] 개인적으로 더 좋다고 생각하는 학습 서적과 비디오 자료를 모아서 그룹 파일에 공유했습니다. 필요한 경우 직접 추가할 수 있습니다! ! ! 그룹에 가입하는 선착순 100명에게는 699 상당의 추가 핵심 정보 패키지(비디오 튜토리얼, 전자책, 실무 프로젝트 및 코드 포함)가 제공됩니다

3. Linux 커널 아키텍처에 대한 간략한 분석

그림 1 Linux 시스템 계층 구조

전면은 사용자(또는 애플리케이션) 공간입니다. 이곳은 사용자 애플리케이션이 실행되는 곳입니다. 사용자 공간 아래에는 커널 공간이 있고, 여기에 리눅스 커널이 위치합니다. GNUCLibrary(glibc)도 여기에 있습니다. 커널에 연결하기 위한 시스템 호출 소켓을 제공하고 사용자 공간 애플리케이션과 커널 간을 변환하는 메커니즘도 제공합니다. 커널과 사용자 공간 애플리케이션은 서로 다른 보호 주소 공간을 사용하기 때문에 이는 중요합니다. 각 사용자 공간 프로세스는 자체 가상 주소 공간을 사용하는 반면 커널은 별도의 주소 공간을 차지합니다.

Linux 커널은 3개 계층으로 더 정의될 수 있습니다. 전면에는 읽기 및 쓰기와 같은 몇 가지 기본 기능을 구현하는 시스템 호출 소켓이 있습니다. 시스템 호출 소켓 아래에는 아키텍처 독립적인 커널 코드로 더 정확하게 정의할 수 있는 커널 코드가 있습니다. 이 코드는 Linux에서 지원하는 모든 프로세서 아키텍처에 공통됩니다. 이 코드 아래에는 일반적으로 BSP(BoardSupportPackage)라고 불리는 것을 구성하는 아키텍처 종속 코드가 있습니다. 이 코드는 특정 아키텍처에 대한 프로세서 및 플랫폼별 코드 역할을 합니다.

Linux 커널은 많은 중요한 아키텍처 속성을 구현합니다. 더 높거나 낮은 수준에서 커널은 하위 시스템으로 정의됩니다. Linux는 모든 기본 서비스를 커널에 통합하므로 전체로 볼 수도 있습니다. 이는 마이크로커널의 아키텍처와 다릅니다. 전자는 통신, I/O, 메모리 및 프로세스 관리와 같은 몇 가지 기본 서비스를 마이크로커널 계층에 삽입합니다. 각 코어에는 고유한 장점이 있지만 여기서는 이에 대해 논의하지 않습니다. 시간이 지남에 따라 Linux 커널은 비디오 메모리 및 CPU 사용량 측면에서 더욱 효율적이었으며 매우 안정적입니다. 그리고 Linux의 가장 흥미로운 점은 이러한 크기와 복잡성에도 불구하고 여전히 뛰어난 이식성을 갖추고 있다는 것입니다. Linux는 다양한 아키텍처 제약 조건과 요구 사항을 지닌 수많은 프로세서와 플랫폼에서 실행되도록 컴파일되었습니다. 반례로는 Linux가 그래픽 메모리 관리 장치(MMU)가 있는 프로세서에서 실행되거나 MMU를 제공하지 않는 프로세서에서 실행될 수 있다는 것입니다.

Linux 커널의 uClinux 포트는 비 MMU에 대한 지원을 제공합니다.

그림 2 Linux 커널 아키텍처

Linux 커널의 주요 구성 요소는 시스템 호출 소켓, 프로세스 관리, 메모리 관리, 가상 파일 시스템, 네트워크 스택, 장치 드라이버 및 하드웨어 아키텍처 관련 코드입니다.

(1) 시스템 호출 소켓

SCI 계층은 사용자 공간에서 커널로 함수 호출을 수행하는 개별 메커니즘을 제공합니다. 위에서 설명한 대로 이 소켓은 동일한 프로세서 제품군 내에서도 아키텍처에 따라 다릅니다. SCI는 실제로 매우 유용한 함수 호출 다중화 및 역다중화 서비스입니다. ./linux/kernel에서 SCI 구현을 찾을 수 있고 ./linux/arch에서 아키텍처 종속 부분을 찾을 수 있습니다.

(2) 프로세스 관리

프로세스 관리의 초점은 프로세스 실행입니다. 커널에서는 이러한 프로세스를 스레드라고 하며 개별 프로세서 가상화(스레드 코드, 데이터, 스택 및 CPU 레지스터)를 나타냅니다. 사용자 공간에서는 프로세스라는 용어가 일반적으로 사용되지만 Linux 구현에서는 이 두 개념(프로세스와 스레드)을 구분하지 않습니다. 커널은 SCI를 통해 애플리케이션 프로그래밍 인터페이스(API)를 제공하여 새로운 프로세스(fork, exec 또는 PortableOperatingSystemInterface[POSIX] 함수)를 생성하고, 프로세스를 중지(kill,exit)하고, 이들 사이의 통신 및 동기화(신호 또는 Then POSIX 메커니즘)를 수행합니다. ).

프로세스 관리에는 활성 프로세스 간에 CPU를 공유해야 하는 필요성을 처리하는 것도 포함됩니다. 커널은 CPU를 놓고 경쟁하는 스레드 수에 관계없이 고정된 시간 내에 작동하는 새로운 유형의 스케줄링 알고리즘을 구현합니다. 이러한 알고리즘을 O(1) 스케줄러라고 합니다. 이름은 여러 스레드를 예약하는 데 걸리는 시간이 하나의 스레드를 예약하는 데 걸리는 시간과 동일함을 의미합니다. O(1) 스케줄러는 다중 프로세서(대칭 다중 프로세서 또는 SMP라고 함)를 지원할 수도 있습니다. ./linux/kernel에서 프로세스 관리를 위한 소스 코드를 찾을 수 있고 ./linux/arch에서 아키텍처 종속 소스 코드를 찾을 수 있습니다.

(3) 비디오 메모리 관리

커널이 관리하는 또 다른 중요한 리소스는 비디오 메모리입니다. 효율성을 높이기 위해 가상 비디오 메모리를 하드웨어로 관리하는 경우 비디오 메모리는 소위 비디오 메모리 페이지 형식(대부분의 아키텍처에서 4KB)에 따라 관리됩니다. Linux에는 사용 가능한 비디오 메모리를 관리하는 방법과 화학적 및 가상 매핑에 사용되는 하드웨어 메커니즘이 포함되어 있습니다. 그러나 비디오 메모리 관리에서는 4KB 버퍼 이상을 관리해야 합니다. Linux는 슬랩 할당자와 같은 4KB 버퍼의 구체적인 표현을 제공합니다. 이러한 메모리 관리 모드는 4KB 버퍼를 기본으로 사용하고, 그로부터 구조를 할당하고, 어떤 메모리 페이지가 가득 찼는지, 어떤 페이지가 완전히 사용되지 않았는지, 어떤 페이지가 비어 있는지 등 메모리 페이지 사용량을 추적합니다. 이를 통해 모드는 시스템 요구에 따라 비디오 메모리 사용량을 동적으로 조정할 수 있습니다. 여러 사용자의 비디오 메모리 사용을 지원하기 위해 때때로 사용 가능한 비디오 메모리가 소모됩니다. 이러한 이유로 Linux 커널에서는 페이지를 비디오 메모리에서 꺼내 c 드라이브에 넣을 수 있습니다. 페이지가 비디오 메모리에서 하드 드라이브로 교환되기 때문에 이 프로세스를 교환이라고 합니다. 비디오 메모리 관리를 위한 소스 코드는 ./linux/mm에서 찾을 수 있습니다.

(4)가상 파일 시스템

가상 파일 시스템(VFS)은 파일 시스템에 대한 범용 인터페이스 표현을 제공하기 때문에 Linux 커널의 매우 유용한 측면입니다. VFS는 SCI와 커널이 지원하는 파일 시스템 간의 교환 계층을 제공합니다(그림 4 참조).

그림 3 Linux 파일 시스템 계층 구조

VFS에서는 열기, 닫기, 읽기, 쓰기 등의 기능을 나타내는 일반적인 API입니다. VFS에는 하위 수준 기능의 구현 방법을 정의하는 파일 시스템 표현이 있습니다. 특정 파일 시스템(50개 이상)을 위한 플러그인입니다. 파일 시스템의 소스 코드는 ./linux/fs에서 찾을 수 있습니다. 파일 시스템 계층 아래에는 특정 파일 시스템과 관계없이 파일 시스템 계층에 대한 공통 기능 세트를 제공하는 버퍼 캐시가 있습니다. 이 캐싱 계층은 일정 기간 동안 데이터를 보관하거나 필요할 때 사용할 수 있도록 나중에 데이터를 미리 가져옴으로써 화학 장비에 대한 액세스를 최적화합니다. 버퍼 캐시 아래에는 특정 화학 장치용 소켓을 구현하는 장치 드라이버가 있습니다.

(5) 네트워크 스택

네트워크 스택은 시뮬레이션된 계약 자체의 계층화된 아키텍처를 따르도록 설계되었습니다. 인터넷 프로토콜(IP)은 전송 계약(일반적으로 전송 제어 계약 또는 TCP라고 함)의 기본이 되는 핵심 네트워크 계층 계약이라는 점을 기억하세요. TCP 내부에는 SCI를 통해 호출되는 소켓 계층이 있습니다. 소켓 계층은 다양한 네트워크 계약을 위한 사용자 소켓을 제공하는 네트워크 하위 시스템의 표준 API입니다. 원시 프레임 액세스부터 IP PDU(계약 데이터 단위), TCP 및 UDP(사용자 데이터그램 프로토콜)에 이르기까지 소켓 계층은 연결을 관리하고 다양한 끝점 간에 데이터를 통신하는 표준화된 방법을 제공합니다. 커널의 네트워크 소스 코드는 ./linux/net에서 찾을 수 있습니다.

(6) 장치 드라이버

Linux 커널의 많은 양의 코드는 특정 하드웨어 장치를 실행할 수 있는 장치 드라이버에 있습니다. Linux 소스 트리는 Bluetooth, I2C, 직렬 등과 같은 다양한 지원 장치로 추가로 정의되는 드라이버 하위 디렉터리를 제공합니다. 장치 드라이버의 코드는 ./linux/drivers에서 찾을 수 있습니다.

(7) 아키텍처 종속 코드

Linux는 실행 중인 아키텍처와 크게 독립적이지만 아키텍처가 제대로 작동하고 더 큰 효율성을 달성하려면 고려해야 할 요소가 있습니다. ./linux/arch 하위 디렉터리는 다양한 아키텍처 관련 하위 디렉터리(함께 BSP를 구성함)를 포함하는 커널 소스 코드의 아키텍처 종속 부분을 정의합니다. 일반적인 데스크탑 시스템의 경우 x86 디렉토리가 사용됩니다. 각 아키텍처 하위 디렉터리에는 다른 많은 하위 디렉터리가 포함되어 있으며 각 하위 디렉터리는 부팅, 커널, 메모리 관리 등과 같은 커널의 특정 측면에 중점을 둡니다. 이 아키텍처 종속 코드는 ./linux/arch에서 찾을 수 있습니다.

Linux 커널의 이식성과 효율성이 충분하지 않은 경우 Linux는 내부에서 분류하기 어려운 몇 가지 다른 기능도 제공합니다. 프로덕션 운영 체제이자 오픈 소스 소프트웨어인 Linux는 새로운 계약과 개선 사항을 테스트하기 위한 좋은 플랫폼입니다. Linux는 고속 네트워크 확장(1기가비트 이더넷[GbE] 및 10GbE 미만)은 물론 기존 TCP/IP를 포함한 광범위한 네트워크 프로토콜을 지원합니다. Linux는 또한 TCP보다 더 많은 중간 기능을 제공하는(전송 계층 계약의 후속 기능인) 스트림 제어 전송 계약(SCTP)과 같은 계약을 지원할 수 있습니다. Linux는 소프트웨어 구성 요소의 동적 추가 또는 삭제를 지원하는 동적 커널이기도 합니다. 동적으로 로드 가능한 커널 모듈이라고 알려진 이 모듈은 부팅 시 요청 시(현재 특정 장치에 모듈이 필요함) 또는 사용자가 언제든지 삽입할 수 있습니다.

Linux의 최신 개선 사항 중 하나는 다른 운영 체제에 대한 운영 체제(하이퍼바이저라고 함)로 사용할 수 있다는 것입니다. 최근 KVM(Kernel-based Virtual Machines)이라는 커널이 변경되었습니다. 이 변경으로 인해 사용자 공간을 위한 새로운 소켓이 활성화되어 다른 운영 체제가 KVM 지원 커널 위에서 실행될 수 있습니다. 다른 Linux 인스턴스를 실행하는 것 외에도 Microsoft Windows도 가상화할 수 있습니다. 유일한 제한 사항은 기본 프로세서가 새로운 가상화 명령을 지원해야 한다는 것입니다.

넷째, 리눅스 아키텍처와 커널 구조의 차이점

1． Linux 아키텍처(즉, Linux 시스템의 구조)에 대해 질문을 받으면 오른쪽 그림을 참조하여 이에 답할 수 있습니다. 큰 관점에서 Linux 아키텍처는 두 부분으로 나눌 수 있습니다.

2． Linux 아키텍처가 사용자 공간과 커널 공간으로 구분되는 이유:

1) 최신 CPU는 일반적으로 다양한 작업 모드를 구현합니다.

ARM을 예로 들어 보겠습니다. ARM은 7가지 작업 모드를 구현하며, CPU가 실행할 수 있는 명령이나 액세스하는 레지스터가 다릅니다.

(2) X86을 예로 들어 보겠습니다. X86은 4가지 권한 수준을 구현합니다. Ring0-Ring3은 권한 있는 명령을 실행할 수 있고 Ring3에는 많은 제한 사항이 있습니다.

2) 따라서 CPU의 관점에서 Linux는 커널의 보안을 보호하기 위해 시스템을 두 부분으로 나눕니다.

3. 사용자 공간과 커널 공간은 프로그램 실행의 두 가지 다른 상태입니다. "시스템 호출"과 "하드웨어 인터럽트"를 통해 사용자 공간에서 커널 공간으로의 전송을 완료할 수 있습니다.

4． Linux 커널 구조(LInux 아키텍처와 Linux 커널 구조의 차이점에 유의하세요)

5. Linux 기반 플랫폼 메커니즘

Linux 플랫폼 드라이버 메커니즘의 기존 device_driver 메커니즘과 비교할 때 매우 중요한 이점은 플랫폼 메커니즘이 자체 리소스를 커널에 등록하고 드라이버에서 이 리소스를 사용할 때 제공된 표준을 사용한다는 것입니다. by platform_device 소켓을 적용하고 사용합니다. 이는 드라이버 및 리소스 관리의 독립성을 향상시키지만 이식성과 보안도 향상됩니다. 다음은 SPI 드라이버 계층의 개략도입니다. Linux의 SPI 버스는 SPI 컨트롤러에서 가져온 버스로 이해할 수 있습니다.

기존 드라이버와 마찬가지로 플랫폼 메커니즘도 세 단계로 나뉩니다.

1. 버스 등록 단계:

커널 시작 초기화 중 main.c 파일의 Kernel_init()→do_basic_setup()→driver_init()→platform_bus_init()→bus_register(&platform_bus_type)는 플랫폼 버스(가상 버스, platform_bus)를 등록합니다.

2. 장비 스테이지 추가:

장치가 등록되면 Platform_device_register()→platform_device_add()→(pdev→dev.bus=&platform_bus_type)→device_add()하여 장치를 가상 버스에 연결합니다.

3. 드라이버 등록 단계:

Platform_driver_register()→driver_register()→bus_add_driver()→driver_attach()→bus_for_each_dev(), 가상 플랫폼버스에 걸려 있는 각 장치에 대해 __driver_attach()→driver_probe_device()를 수행하고 drv→bus→match() 실행 여부를 결정합니다. 성공하면 이때 watch 포인터를 통해 platform_match→strncmp(pdev→name,drv→name,BUS_ID_SIZE)를 실행하고 일치하면 really_probe(실제로는 해당 장치의 platform_driver→probe(platform_device)를 실행)를 호출하여 시작한다. 실제 감지가 성공하면 장치가 드라이버에 바인딩됩니다.

플랫폼 메커니즘이 마침내 세 가지 핵심 함수인 버스_레지스터(), 디바이스_추가(), 드라이버_레지스터()를 호출하는 것을 내부에서 볼 수 있습니다.

Platform_device 구조는 일반적인 장치 구조 structdevicedev, 장치 리소스 구조 structresource*resource 및 장치 이름 constchar*name을 포함하는 플랫폼 구조 장치를 설명합니다. (이 이름은 이전 platform_driver.driveràname과 동일해야 하며 이유는 앞에서 설명합니다.)

이 구조에서 가장 중요한 것은 리소스 구조이며, 이것이 플랫폼 메커니즘이 도입된 이유입니다.

이름이 같아야 하는 이유:

여기에 언급된 드라이버는 등록 시bus_for_each_dev() 함수를 호출하고 가상 플랫폼버스에 걸려 있는 각 장치에 대해 __driver_attach()→driver_probe_device()를 수행합니다. 이 함수에서는 dev와 drv가 일치를 위해 예비적으로 함수를 가리킵니다. to by drv->bus->match가 호출됩니다. platform_driver_register 함수에서 drv->driver.bus=&platform_bus_type이므로 drv->bus->match는 platform_bus_type→match, 즉 platform_match 함수입니다.

dev와 drv의 이름을 비교하는 것입니다. 동일하면 really_probe() 함수로 들어가므로 추가 일치를 위해 직접 작성한 프로브 함수로 들어갑니다. 따라서 초기화 시 dev→name과 드라이버→drv→name을 동일하게 채워야 합니다.

드라이버 유형에 따라 일치 기능이 다릅니다. 이 플랫폼의 드라이버는 dev와 drv의 이름을 비교합니다. USB 드라이버의 일치 항목을 기억하십니까? ProductID와 VendorID를 비교합니다.

플랫폼 메커니즘의 이점에 대한 개인 요약:

1. platform_bus_type 버스를 제공하고 버스 유형이 아닌 SOC 장치를 이 가상 버스에 추가합니다. 결과적으로 버스-장치-드라이버 모델이 대중화될 수 있습니다.

2. platform_device 및 platform_driver 유형 데이터 구조를 제공하여 기존 장치 및 드라이버 데이터 구조를 포함하지만 리소스 멤버를 추가하여 장치 리소스를 동적으로 전송하는 OpenFirmware와 같은 새로운 부트로더 및 커널과 쉽게 통합할 수 있습니다.

Six, Linux 커널 아키텍처

Linux 커널은 단일체이기 때문에 다른 유형의 커널보다 가장 큰 공간을 차지하고 가장 복잡합니다. 이는 Linux 초기에 상당한 논란을 불러일으켰던 설계 기능이지만 여전히 단일 커널에 내재된 동일한 설계 결함 중 일부를 안고 있습니다.

이 결함을 해결하기 위해 Linux 커널 개발자가 수행한 작업 중 하나는 런타임에 커널 모듈을 로드 및 언로드 가능하게 만드는 것입니다. 즉, 커널 기능을 동적으로 추가하거나 제거할 수 있습니다. 커널에 하드웨어 기능을 추가하는 것 외에도 낮은 수준의 가상화와 같은 서버 프로세스를 실행하기 위한 모듈도 포함될 수 있지만 개별적인 경우 컴퓨터를 다시 시작할 필요 없이 전체 커널을 교체할 수도 있습니다.

재부팅하지 않고도 Windows 서비스 팩으로 업그레이드할 수 있다고 상상해보세요...

세븐, 커널 모듈

Windows에 이미 사용 가능한 드라이버가 모두 설치되어 있고 필요한 드라이버만 켜면 어떻게 됩니까? 이는 기본적으로 Linux에서 커널 모듈이 수행하는 작업입니다. LKM(로드 가능한 커널 모듈)이라고도 하는 커널 모듈은 사용 가능한 비디오 메모리를 모두 소모하지 않고 커널이 모든 하드웨어에서 작동하도록 유지하는 데 필요합니다.

모듈은 일반적으로 기본 커널에 장치, 파일 시스템, 시스템 호출 등의 기능을 추가합니다. lkm의 파일 확장자는 .ko이며 일반적으로 /lib/modules 디렉터리에 저장됩니다. 모듈의 특성상 시작 시 menuconfig 명령을 사용하여 모듈을 로드하거나 로드하지 않도록 설정하거나, /boot/config 파일을 편집하거나, modprobe 명령을 사용하여 모듈을 동적으로 로드 및 언로드하는 방식으로 커널을 쉽게 사용자 정의할 수 있습니다.

Ubuntu와 같은 일부 배포판에서는 타사 및 비공개 소스 모듈을 사용할 수 있는데, 이러한 모듈의 소스 코드를 사용할 수 없기 때문에 기본적으로 설치하기 어려울 수 있습니다. 소프트웨어 개발자(예: nVidia, ATI 등)는 소스 코드를 제공하지 않지만 대신 자체 모듈을 구축하고 배포에 필요한 .ko 파일을 컴파일합니다. 실제로 이러한 모듈은 맥주처럼 무료이지만 말처럼 자유롭지 않으므로 일부 배포판에는 포함되지 않습니다. 왜냐하면 관리자는 이것이 비자유 소프트웨어를 제공함으로써 커널을 "오염"시킨다고 느끼기 때문입니다.

커널은 마법이 아니지만 제대로 작동하는 모든 컴퓨터에 필수적입니다. Linux 커널은 커널 수준 드라이버를 포함하고 "즉시" 사용할 수 있는 많은 작업을 가능하게 한다는 점에서 OSX 및 Windows와 다릅니다. 소프트웨어와 하드웨어가 함께 작동하는 방법과 컴퓨터를 시작하는 데 필요한 파일에 대해 자세히 알아보시기 바랍니다.

결론: 관심의 힘은 무한합니다. 관심이 열정을 가져올 수 있다면, 일에 대한 열정이 생길 것입니다. 이처럼 일은 단순한 일이 아니라 일종의 즐거움이기도 합니다.

위 내용은 Linux 커널 준비 작업 이해: C 언어 및 운영 체제에 대한 약간의 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!