내 의견은 그렇습니다. 외부 세계(권한 없는 프로세서 모드)에 대한 모든 유용한 노출에는 먼저 외부 세계에서 실행되는 프로세스가 필요하기 때문입니다. 이를 위해서는 파일 시스템, 심지어 임시 RAM 내 파일 시스템도 필요합니다.
다른 엔지니어는 내 의견에 동의하지 않지만 모든 (내가 알지 못하는) 상황에서 그것을 증명할 수는 없는 것 같습니다.
이 질문에 대한 대답은 "실행"의 정의에 따라 달라지나요?
답변1
커널을 프로그램처럼 실행하지 않기 때문에 이것은 다소 이상한 문제입니다. 커널은 프로그램이 실행되는 플랫폼입니다. 물론 설정 및 종료 코드가 있지만 커널만 단독으로 실행하는 것은 불가능합니다. 항상 기본 "init" 프로세스가 있어야 합니다. 존재하지 않으면 커널 패닉이 발생합니다. init가 커널 종료를 시도하는 경우에도 패닉이 발생합니다.
오늘날 init 프로세스는 systemd와 유사합니다. 달리 지정하지 않으면 커널은 로 시작하는 위치 목록에서 프로그램을 실행하려고 시도합니다 /sbin/init. 여기에서 초기화 매개변수를 참조하세요.http://man7.org/linux/man-pages/man7/bootparam.7.html긴급 상황에서는 를 사용하여 Linux를 부팅할 수 있습니다 init=/bin/bash. 그러나 실행할 파일 시스템에서 항상 파일을 지정하는 방법에 유의하십시오.
따라서 파일 시스템 없이 커널이 시작되면 파일 시스템 없이는 init를 로드할 수 없기 때문에 패닉이 발생합니다.
커널의 초기화 단계로 인해 약간의 혼란이 발생할 수 있습니다. 초기 램디스크는 디스크의 이미지에서 로드되며 중요한 드라이버와 설치 스크립트를 포함합니다. 이는 파일 시스템이 로드되기 전에 실행됩니다. 그러나 초기 램디스크 자체가 파일 시스템이라는 점에는 의심의 여지가 없습니다. 초기 램디스크를 호출합니다 /init(초기 램디스크에 저장되어 있음). 많은 배포판에서 최종 호출은 this 입니다 /sbin/init. 다시 말하지만 이는 파일 시스템 없이는 불가능합니다.
답변2
대답은 문자 그대로 파일 시스템이 없다는 뜻인지, 아니면 질문이 실제로 언급된 방식과 약간 다르게 해석되는지에 따라 달라집니다. 질문에 대한 약간 다른 해석의 답변은 다음과 같습니다.
- 프로그램 없이 Linux 실행블록 장치일부 특별한 사용 사례에는 완벽하게 실행 가능하고 유용합니다.
- 프로그램 없이 Linux 실행파일 시스템커널 코드의 일부 부분을 다시 작성해야 하며 이는 유용한 작업이 아닐 가능성이 높습니다.
- 프로그램을 사용하지 않고 Linux 실행파일 설명자많은 노력이 필요합니다. 나는 그것이 노력할 가치가 없다고 확신합니다.
파일 시스템 없이 작동하는 시스템을 만들기 위해 커널 코드의 일부를 다시 작성해야 하는 이유는 다음과 같습니다.
- 각 스레드에는 루트 디렉터리와 일부 파일 시스템을 가리켜야 하는 현재 작업 디렉터리가 있습니다.
execve프로그램은 파일 시스템에 실행 파일이 필요한 시스템 호출에 의해 시작됩니다.- 커널은 부팅 프로세스 중에 메모리 기반 파일 시스템을 생성합니다.
프로그램이 시작된 후 execve이를 시작한 실행 파일의 매핑을 해제할 수 있지만 즉시 충돌하지 않고 이를 수행하려면 먼저 파일이 지원하지 않는 실행 가능한 메모리 맵을 생성한 후 해당 파일로 점프하여 매핑을 해제해야 합니다. 파일이 생성되면 유용한 코드로 초기화해야 합니다.
따라서 실행 중인 사용자 모드 프로그램은 파일 지원 메모리 매핑이 없는 상태로 존재할 수 있으며 파일이 지원하는 모든 파일 설명자가 닫힐 수 있습니다. 루트 디렉토리와 현재 작업 디렉토리를 갖는 것을 멈출 수는 없지만 이를 피할 수는 있습니다.
따라서 이 상태에서는 커널 코드를 구현하여 프로그램에서 파일 시스템을 제거하고 계속 실행되도록 할 수 있지만 이는 유용하지 않을 것 같습니다. 파일 시스템을 사용하는 중간 상태를 거치지 않고 최종 상태에 도달하려면 더 많은 작업이 필요하고 아무런 이점도 얻지 못합니다.
일부 특별한 사용 사례에 유용한 설정
블록 장치를 사용하지 않는 것이 유용할 수 있습니다. 부팅하는 동안 커널은 메모리 내 파일 시스템을 생성하고 cpio실행 전에 해당 파일 시스템을 아카이브의 콘텐츠로 채울 수도 있습니다 init. 이렇게 하면 블록 장치 지원 없이 메모리 기반 파일 시스템에서 시스템을 완전히 실행할 수 있습니다.
이는 상태를 유지하지 않고 재부팅 시 시스템을 처음부터 시작하려는 시스템에 유용합니다.
물론, 커널이 제어할 수 있으려면 커널과 cpio 아카이브가 메모리에 어떻게든 존재해야 합니다. 그들이 거기에 도달하는 방법은 부트로더의 임무입니다. 최종 실행 시스템이 블록 장치를 사용하지 않더라도 부트로더는 블록 장치에서 이러한 내용을 로드할 수 있습니다. 그러나 부트로더는 네트워크를 통한 부팅과 같은 블록 장치를 사용하지 않고도 커널 및 cpio 아카이브를 얻을 수도 있습니다.
답변3
리눅스에서는 거의각 장치는 파일입니다이므로 이를 실행하려면 파일 시스템이 있어야 합니다.
답변4
커널은 다른 프로그램과 마찬가지로 프로그램입니다. 기본적으로 Linux 커널은 파일 시스템에 액세스하려고 시도하지만 이 동작은 커널을 수정하여 쉽게 제거할 수 있습니다(실제로 "arch_call_rest_init()" 함수만 추가하면 됩니다). "유용한 작업"을 수행하기 위해 개발자는 사용자 정의 드라이버에 커널 스레드(kthread)를 포함하여 일부 필수 초기화 및 애플리케이션 유형 작업 부하를 수행할 수 있을 것으로 기대합니다. Linux 커널에는 이미 많은 kthread가 포함되어 있지만 주로 커널이나 드라이버에 대한 보조 작업을 수행합니다. 커널 컨텍스트에서 사용할 수 있는 API는 Linux 사용자 공간에서 사용할 수 있는 API와 매우 다릅니다. 파일 시스템이 없는 시나리오에서는 시스템 호출 기능의 상당 부분이 쓸모 없게 됩니다.
예, Linux는 기본적으로 파일 시스템에 대한 액세스를 기대합니다. 아니요, 수정된 커널은 파일 시스템 없이도 유용한 작업을 수행할 수 있습니다. 내 생각에는 파일 시스템이 없는 Linux의 실제 사용은 상당히 제한적이지만 제로는 아닙니다. FWIW, 과거에는 많은 실시간 커널이 RT 애플리케이션과 동일한 네임스페이스 및 바이너리에 구축되었습니다.