리눅스 부팅 시퀀스가 ​​sh가 아닌 c 인 이유는 무엇입니까?


5

나는 리눅스를 실행하는 임베디드 장치를 가지고있다.

부트 시퀀스의 속도를 높이려고합니다. C에서 부팅 시퀀스의 큰 부분을 다시 작성하면 속도가 훨씬 빨라 집니까?

예를 들어 나는 이것을 테스트하거나 스크립트를 많이 가지고있다가 이것을 마운트한다. 이것은 /etc/rcS.d/S03sysfs입니다.

#!/bin/sh

if [ -e /proc ] && ! [ -e /proc/mounts ]; then
  mount -t proc proc /proc
fi

if [ -e /sys ] && grep -q sysfs /proc/filesystems; then
  mount sysfs /sys -t sysfs
fi

exit 0

제 추측으로는 C 언어에 있다면 훨씬 더 빠를 것입니다.

내 질문 :

왜 아직 C 언어로되어 있지 않은가?
C로 이것을 작성하는 속도가 있습니까?

답변:


9

그것은 될 것입니다. 약간 C에서 더 빠르지 만 언어 선택은 성능에 가장 큰 영향을 미치지 않습니다. 일반적으로 더 간단한 init 시스템처럼 각 태스크가 순차적으로 완료되기를 기다리는 대신 여러 태스크를 병렬로 수행하는 것이 더 효과적입니다. 예를 들어, sshd httpd 같은 시간에 시작할 수 있습니다. 둘 다 이미 실행 중이어야하기 때문에


단일 "Linux 부팅 순서"는 없습니다. 각 배포판에는 자체 배포본이 있습니다. 그들 모두가 공통점이있는 것은 하나도 없습니다. 그것 양철통 C, Perl, Haskell, 뭐든지 될 수 있습니다. 유일한 요구 사항은 실행 파일이 /init initramfs에 존재해야한다. /sbin/init 루트 파일 시스템에서.

그만큼 /etc/rc?.d 체계는 단순히 20 년 전, 심지어 30 년 후의 유닉스 부팅 과정의 확장 일 뿐이다. 가장 초기의 유닉스 시스템은 아주 드물게 재부팅 되었기 때문에 간단한 스크립트 만 가지고 있었을 것이다. /etc/rc 또는 유사한 초기화 순차적으로 다양한 데몬을 시작하십시오.

오늘도 SysV 초기화 정확한 방법이 다를 수 있지만 이러한 스크립트를 모두 시작하는 데 사용됩니다. 원래 시스템은 모든 스크립트를 시작합니다. /etc/rc?.d 순서대로; 현재 데비안은 Makefile 스타일의 의존성을 사용합니다.

일부 배포판 - 우분투, 크롬 OS, 페도라 (v14) -로 전환했습니다. 건방진 녀석 이것은 C로 작성되고 "이벤트 기반"이므로 데몬을 병렬로 시작할 수 있습니다. 또 다른 init 시스템, 시스템 , 인기 급상승중인 것으로 보입니다. Fedora와 OpenSuSE에서 기본적으로 사용됩니다. 이것은 또한 C로 작성됩니다 (두 시스템은 여전히 ​​어떤 데몬을 시작할지 결정하기 위해 텍스트 구성 파일을 읽습니다).

여전히 SysVinit을 사용하는 배포판은 "단순함"을 위해 일반적으로 사용합니다. 가장 일반적으로들은 [표창장은 필요로했다] 인자는 동등한 C 코드 (쉘 스크립트가 90 % copypasta로 구성되어 있음에도 불구하고)보다 유지하기 쉬운 쉘 스크립트에 관한 것으로 보이며 추가 라이브러리 의존성을 도입 할 필사적 인 두려움 [주걱] . 에서 직접 볼 수 있습니다. , , 2012 년 5 월의 데비안 메일 링리스트의 토론 스레드.

(면책 조항 : 나는 시스템 사용자 자신).



내 장치에는 단 하나의 코어 만 있으므로 병렬 작업은 속도를 크게 향상시키지 않을 것입니까? 내 시동이 많이 차단되지 않는다면 ... 그렇지?
user1190

@ user1190 : 입출력 대기는 공통 블록이므로 단일 코어에서도 이익을 볼 수 있습니다.
Daenyth

5

왜 아직 C 언어로되어 있지 않은가?

플랫폼 간 호환성 및 sh 파일을 사용하여 부팅 프로세스를 설명 할 수 있기 때문입니다. C에서 부팅 스크립트를 유지 관리하는 것은 PITA가됩니다.

C로 이것을 작성하는 속도가 있습니까?

별로. 일부 부품은 더 빠르지 만 전체적인 속도 향상은 미약합니다. 부트 프로세스의 대부분은 엄격하게 순차적이며 특히 init 1과 2의 단계입니다. init 3 이상에서 부트 프로세스는 다음과 같은 것을 사용하여 평행 화 될 수 있습니다 루밋 , 그것은 당신에게 큰 속도 향상을 가져다 줄 것입니다.


부팅 스크립트는 100 % C 코드 일 필요는 없습니다. 그들은 텍스트 구성 파일 (예 : fstab 파일 시스템 용) 예를 들어,이 .
grawity

1
왜 GCC는 바이너리 패키지로 배포 될 수있는 프로그램에 대한 의존성이 될까요? sysvinit도 C로 작성되었다는 것을 기억하십시오. (또한 여러 Arch 패키지의 관리자로서, 훨씬 쉽게 배포판마다 차이가 나는 20 행 쉘 스크립트보다 모든 곳에서 작동하는 5 줄 단위 파일의 일관성을 보장합니다.)
grawity

1
init 시스템 자체는 이미 C로 작성되었으며 컴파일러는 Build-Dep로되어 있습니다. 반면에, 각 서비스에 대한 스크립트는 전혀 스크립트 일 필요는 없습니다. 그들은 간단 할 수있다. 텍스트의 구성 파일은 이전 예제에서와 같습니다. 컴파일 할 이유가 없습니다.
grawity

2
@grawity : 텍스트 파일을 "scripts"라고하고 C 코드를 "shell"이라고 부를 수 있습니다. 진지하게, 어떤 종류의 속도 향상을 얻을 수 있다고 생각하십니까? 쉘이 이미 RAM으로 읽혀질 것이라는 점을 명심하십시오,이 페이지에 언급되어있는 다른 이유와 관리자의 고통이 아주 적은 작은 성능 이득 ...
mpez0

1
한 가지 차이점은 sh 스크립트는 많은 수의 외부 프로그램에 의존합니다. 그것들이 메모리에 캐시되어 있어도, fork ()하는 것은 여전히 ​​하나의 mount () 시스템 콜의 비용보다 크다 (OP의 예에서와 같이). 관리자 고통에 관해서는, 내가 지금까지 본 유일한 변화는 감소 . (나는 이번 주에 제 3의 flamewar에 관여하고 있다고 느낀다. 나는 멈춰야한다.)
grawity

2

대부분의 시간을 보내는 데는 파일 시스템, 네트워크 등이 차례로 기다리고 있습니다.

네가 원하면 정말 빠른 부팅 순서, init = / bin / sh로 부팅 - 즉시 명령 프롬프트! 임베디드 시스템이라면 응용 프로그램으로 직접 부팅 할 수 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.