ac 프로그램을 커널의 init 프로그램으로 사용하려면 왜 정적으로 링크해야 합니까?

ac 프로그램을 커널의 init 프로그램으로 사용하려면 왜 정적으로 링크해야 합니까?

나는 Linux가 어떻게 작동하는지 배우고 그것을 지켜보고 있습니다.튜토리얼: 가장 간단한 Linux 시스템 구축저자: 롭 랜드리. 그는 기본적으로 최소한의 시스템을 구축하고 이를 중심으로 구축하기 위해 몇 가지 단계를 거칩니다.20:00그는 만드는 방법을 설명하기 시작했습니다."안녕하세요 월드 바이너리"그는 나중에 이를 커널의 초기화 프로그램으로 실행하는 첫 번째 프로그램으로 사용할 것입니다.

제 질문은 커널 부팅 후 실행되는 init 애플리케이션으로 사용하려는 hello.c 애플리케이션을 왜 정적으로 링크해야 하느냐는 것입니다(예:21:39그리고 보았다23:05)?

답변1

내 질문은 커널 부팅 후 실행되는 init 애플리케이션으로 사용하려는 hello.c 애플리케이션을 정적으로 빌드해야 하는 이유입니다(21:39에 언급되고 23:05에 표시됨).

바닐라 Linux 커널에는 그러한 요구 사항이 없습니다. 초기화 프로그램과 공유 종속성을 로드합니다.

$ ls -la /sbin/init
lrwxrwxrwx. 1 root root 22 Nov 15 13:21 /sbin/init -> ../lib/systemd/systemd

$ ldd `which /sbin/init`
    linux-vdso.so.1 (0x00007ffcd31ee000)
    libsystemd-shared-249.so => /usr/lib/systemd/libsystemd-shared-249.so (0x00007fd28d983000)
    libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fd28d950000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fd28d925000)
    libmount.so.1 => /lib64/libmount.so.1 (0x00007fd28d8e0000)
    libpam.so.0 => /lib64/libpam.so.0 (0x00007fd28d8ce000)
    libaudit.so.1 => /lib64/libaudit.so.1 (0x00007fd28d8a0000)
    libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fd28d883000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd28d868000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fd28d65e000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00007fd28d653000)
    libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fd28d61b000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00007fd28d611000)
    libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007fd28d5d5000)
    libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fd28d499000)
    libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007fd28d48f000)
    liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fd28d46b000)
    libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fd28d17d000)
    libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fd28d04b000)
    libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fd28cf73000)
    liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fd28cf47000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fd28de62000)
    libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fd28ceb0000)
    libeconf.so.0 => /lib64/libeconf.so.0 (0x00007fd28cea5000)
    libm.so.6 => /lib64/libm.so.6 (0x00007fd28cdc9000)
    libcap-ng.so.0 => /lib64/libcap-ng.so.0 (0x00007fd28cdbe000)
    libz.so.1 => /lib64/libz.so.1 (0x00007fd28cda4000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00007fd28cd9c000)
    libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fd28cd76000)
    libpcap.so.1 => /lib64/libpcap.so.1 (0x00007fd28cd29000)
    libffi.so.6 => /lib64/libffi.so.6 (0x00007fd28cd1c000)
    libibverbs.so.1 => /lib64/libibverbs.so.1 (0x00007fd28ccfa000)
    libnl-route-3.so.200 => /lib64/libnl-route-3.so.200 (0x00007fd28cc74000)
    libnl-3.so.200 => /lib64/libnl-3.so.200 (0x00007fd28cc50000)

답변2

init 프로그램은 execve 시스템 호출을 지원하는 내부 커널 코드로 실행될 수 있는 모든 프로그램이 될 수 있습니다.

많은 시스템이 쉘 스크립트를 사용하지만 Python 스크립트일 수도 있습니다.

정적으로 링크된 바이너리인 init 프로그램의 장점은 종속성이 적다는 것입니다. 따라서 런타임 링커와 링크되는 공유 라이브러리가 필요하지 않습니다.

64비트 x86 시스템에서는 초기 파일 시스템 및 init 프로그램에 /lib64/ld-linux-x86-64.so.2 및 /lib/x86_64-linux-gnu/libc.so.6과 같은 것이 필요할 수 있습니다. 그 자체.

관련 정보