홈페이지>프로그래밍 관련>기타 소스코드
다운로드

Smart-OS 작은 Linux 시스템

이 프로젝트는 작고 완벽하게 작동하는 Linux 운영 체제를 신속하게 만드는 방법을 보여줍니다. 프로젝트 주소는 https://github.com/superconvert/smart-os입니다

기능과 기능

  1. 여러 하드 디스크의 마운트를 지원합니다
  2. 네트워크 기능, DNS 해상도를 지원합니다
  3. GCC 컴파일러, C, C ++를 지원합니다
  4. QEMU 모드 시작을 지원합니다
  5. Docker Startup을 지원하십시오
  6. 시스템의 가장 간소화 된 모드 64m 크기
  7. 운전자 제작 관련 데모를 지원합니다
  8. 방화벽 iptables를 지원합니다
  9. 원격 서비스 OpenSsh-Server를 지원합니다
  10. 데스크탑 시스템 XFCE4 데스크탑을 지원합니다화신
  11. 일반적으로 중고 도구 세트 LSHW, LSPCI, LSOF, Strace 등을 지원합니다.
  12. https://github.com/superconvert/smart_rtmpd를 실행하는 Smart_rtmpd 스트리밍 서버를 지원합니다

목적과 시나리오

  1. 운영 체제 원칙 교육
  2. 클라우드 호스트 시스템
  3. 맞춤형 스트리밍 서버
  4. 맞춤형 임베디드 장치
  5. IoT 시나리오 운영 체제 사용자 정의

TODO 목록

  1. 팔 버전을 추가하십시오
  2. 그래픽 인터페이스 데모가 추가되었습니다
  3. ISO 생산 지원
  4. 시간대

아이디어의 전반적인 진화

  1. 생산을 위해 서버 버전을 선택하는 이유는 무엇입니까?
    서버 버전에는 창 시스템이 의존하는 대부분의 패키지가 포함되어 있지 않습니다. 시스템에 이러한 패키지가 제공되면 여러 버전의 패키지, 컴파일 문제, 종속성 문제, 링크 문제 및 런타임 문제에 문제가있어 작업에 많은 간섭이 발생합니다. 또한 이러한 문제를 해결하는 것은 의미가 없으므로 순수한 버전의 종속성 패키지가 필요합니다.

  2. 윈도우 시스템이 왜 그렇게 크게 작동합니까?
    APT를 사용하여 설치하는 모든 패키지 (도구 제외)는 이론적으로 패키지의 종속성 및 접착력을 포함하여 소스 코드를 컴파일해야합니다. 이것은 매우 큰 작업량입니다. 새로운 시스템에는 아무런 방법이 없으며 필요한 환경을 우리가 제공해야합니다. 프로젝트 A는 패키지 B에 따라 다르고 패키지 B는 패키지 C, 패키지 C 및 패키지 C에 따라 패키지 d에 따라 다릅니다. 우리가해야 할 일은 모든 패키지를 컴파일하는 것입니다!

생산 과정

이 스크립트는 우분투 18.04에서 만들어졌습니다. 다른 시스템은 크게 변경되어서는 안됩니다. 필요한 친구는 직접 수정할 수 있습니다.

  1. 시스템 환경을 준비하십시오. 커널을 컴파일해야하므로 커널 컴파일에 필요한 환경을 설치해야합니다. BusyBox를 컴파일해야하므로 필요에 따라 필요한 환경을 직접 설치할 수 있습니다. 

    ./00_build_env.sh

  2. 소스 코드 컴파일 (커널, glibc, busybox, gcc, binutils) 

    ./01_build_src.sh

  3. 시스템 디스크 생성 (중요,이 단계는 시스템 파일에 시스템을 설치합니다) 

    ./02_build_img.sh

  4. Smart-OS 시스템을 실행하십시오 

    ./03_run_qemu.sh 或 ./04_run_docker.sh

운영 체제를 쉽게 만들 수 있습니까? 디스크 공간은 임의로 확장되고 온라인으로 액세스 할 수 있으며 필요에 따라 확장 할 수 있습니다. Smart-OS에서 스트리밍 서버 Smart_RTMPD를 성공적으로 시도했습니다.

네트워크 토폴로지 다이어그램 

+----------------------------------------------------------------+-----------------------------------------+-----------------------------------------+  
|                          Host                                  |              Container 1                |              Container 2                |  
|                                                                |                                         |                                         |  
|       +------------------------------------------------+       |       +-------------------------+       |       +-------------------------+       |  
|       |             Newwork Protocol Stack             |       |       |  Newwork Protocol Stack |       |       |  Newwork Protocol Stack |       |  
|       +------------------------------------------------+       |       +-------------------------+       |       +-------------------------+       |  
|               +                    +                           |                   +                     |                    +                    |
| ............... | .................... | ........................... | ................... | ..................... | .................... | .................... |
|               +                    +                           |                   +                     |                    +                    |
|        +-------------+    +---------------+                    |           +---------------+             |            +---------------+            |
|        | 192.168.0.3 |    | 192.168.100.1 |                    |           | 192.168.100.6 |             |            | 192.168.100.8 |            |
|        +-------------+    +---------------+     +-------+      |           +---------------+             |            +---------------+            |
|        |     eth0    |    |      br0      | < --- > |  tap0 |      |           |      eth0     |             |            |      eth0     |            |
|        +-------------+    +---------------+     +-------+      |           +---------------+             |            +---------------+            |
|               +                   +                 +          |                   +                     |                    +                    |
|               |                   |                 |          |                   |                     |                    |                    |
|               |                   +                 +------------------------------+                     |                    |                    |
|               |               +-------+                        |                                         |                    |                    |
|               |               |  tap1 |                        |                                         |                    |                    |
|               |               +-------+                        |                                         |                    |                    |
|               |                   +                            |                                         |                    |                    |
|               |                   |                            |                                         |                    |                    |
|               |                   +-------------------------------------------------------------------------------------------+                    |
|               |                                                |                                         |                                         |
|               |                                                |                                         |                                         |
+--------------- | ------------------------------------------------+-----------------------------------------+-----------------------------------------+
                +
     Physical Network  (192.168.0.0/24)

주목해야 할 것

  1. Smart-OS는 GLIBC Dynamic 라이브러리를 설치하기 때문에 동적 라이브러리 로더/링커 LD-LINUX-X86-644에 크게 의존합니다. 응용 프로그램은 동적 컴파일을 통해 연결되므로 동적 연결이 필요한 응용 프로그램이 운영 체제에 의해로드되면 시스템은 필요한 모든 동적 라이브러리 파일을 찾아로드해야합니다. 이 작업은 ld-linux.so.2에 의해 수행됩니다. 프로그램이로드되면 운영 체제는 프로그램의 일반 입력 주소 대신 LD-Linux.에 제어를 넘겨줍니다. LD-Linux.so.2는 필요한 모든 라이브러리 파일을 찾고로드 한 다음 응용 프로그램의 시작 포털에 컨트롤을 넘겨줍니다. ld-linux-x86-64.so.2는 실제로 ld-linux.so.2의 소프트 체인입니다. /lib64/ld-linux-x86-644.so.2에 따라 존재해야합니다. 그렇지 않으면 동적으로 컴파일 된 BusyBox는 GLIBC 라이브러리에 따라 다릅니다. GLIBC 라이브러리의 로딩에는 LD-LINUX-X86-64가 필요합니다. /lib64 디렉토리에 존재하지 않으면 시스템이 직접적으로 파괴됩니다. 이 문제는 특별한주의가 필요합니다! ! !

  2. QEMU는 일반적으로 시작 후 작은 창이 있습니다. 오류가 발생하면 기본적으로 오류 로그를 읽을 방법이 없습니다. 그런 다음 Grub의 시작 항목에 Console = Ttys0을 추가해야합니다. 동시에 QEMU-SYSTEM-X86_64 파일에 직렬 포트 출력을 추가합니다 .Serial 파일 : ./ qemu.log, 디버깅이 훨씬 편리합니다. 디버깅 후 콘솔 = ttys0을 제거해야합니다. 그렇지 않으면 /etc/init.d/rcs의 내용이 표시되지 않을 수 있습니다.

  3. 우리가 컴파일 한 glibc의 버전은 일반적으로 시스템과 함께 제공되는 버전보다 높습니다. GLIBC가 성공적으로 편집되었는지 테스트 프로그램 Main.c를 작성할 수 있습니다. 예를 들어: 

    # include < stdio.h >
int main () {
    printf ( " Hello glibc n " );
    return 0 ;
}

    우리는 컴파일합니다 

    gcc -o test main.c -Wl,-rpath=/root/smart-os/work/glibc_install/usr/lib64

    우리는 ./test 프로그램을 성공적으로 실행하고 일반적 으로이 /lib64/libc.so.6과 유사한 오류를보고합니다. 실제로 이것이 지정된 동적 라이브러리 로더/링커 및 시스템 환경이없는 이유입니다. 일반적으로 GLIBC 라이브러리를 컴파일하면 컴파일 디렉토리가 TestRun.sh 스크립트 파일을 자동으로 생성하고 컴파일 디렉토리에서 프로그램을 실행합니다. 

    ./testrun.sh ./test

    이것은 일반적으로 성공적으로 수행됩니다. 또한 다음 문장을 스크립트에 저장할 수 있으며 테스트를 실행해도 괜찮습니다. 

     exec env /root/smart-os/work/glibc_install/lib64/ld-linux-x86-64.so.2 --library-path /root/smart-os/work/glibc_install/lib64 ./test

  4. 실행 가능한 프로그램에 의해로드 된 라이브러리를 어떻게 추적합니까? ld_debug = libs ./test 만 사용하십시오. 우리는 도서관을 사전로드하고 LIBRIANT를 예비로드하여 LD_PRELOAD를 사용하여 라이브러리를 예압합니다.

  5. 우리가 카이로를 컴파일 할 때, 우리는 보통 많은 문제가 발생합니다. 카이로 편집에 문제가 있으면 어떻게해야합니까? 일부 오류 메시지는 인터넷에서 검색하기가 어렵습니다. 컴파일 중에 Config.Log 파일이 생성됩니다. 오류 메시지는 매우 상세합니다! 신속한 정보에 따라 문제를 해결할 수 있습니다.

  6. Busybox의 Init System 변수에 대해 Grub의 커널 매개 변수를 사용하더라도 환경 변수를 통과 할 수는 없습니다. Busybox의 Init는 기본 환경 변수 경로를 자동으로 생성하므로 사용자 정의 된 경로를 지원하기 위해 소스 코드를 변경해야합니다. 물론 쉘의 로그인 모드는 /etc /profile을 읽습니다. 로그 인 모드의 경우이 모드가 유효하지 않으므로 /etc /프로파일을 전달하는 제한이 있습니다.

libxcb의 편집, 자세한 내용은 mk_xorg.sh를 참조하십시오.

  1. APT 설치 -Y Python -XCBGEN 라이브러리를 설치해야합니다. 이 라이브러리는 XCBProto에서 제공하는 XML 파일을 기반으로 해당 H 파일 및 C 파일을 생성합니다.
  2. 변수 내보내기 PKG_CONFIG_SYSROOT_DIR = "$ {XCLIENT_DIR}"를 추가하십시오. 그렇지 않으면 컴파일 중 XML 파일을 찾는 경로가 올바르지 않습니다.
  3. 변수 내보내기 pkg_config_path = "$ {xclient_dir}/usr/share/pkgconfig : $ {xclient_dir}/usr/lib/pkgconfig : $ {xclient_dir}/usr/local/lib/pkgconfig", 그렇지 않으면 pkg-cludit XCB-Proto는 제대로 작동하지 않습니다
  4. 변수 내보낼 XCBPROTO_XCBINCLUDEDEDIR = "$ {XCLIENT_DIR}/usr/share/xcb"XML 파일이 위치한 올바른 경로입니다.
  5. XCBGEN 모듈 경로를 구성하려면 변수 내보낼 PythonPath = "$ {xclient_dir} /usr/lib/python2.7/dist-packages"를 추가하십시오.
  6. libxcb의 파일 src/c_client.py를 편집하여 범위가 아닌 유니 코데 컨코드 테러의 문제를 해결하십시오 (128). Python의 기본 문자 세트는 ascii code sed -i "8 i Reload (sys)"src/c_client.py sed -i "9 i sys.setDefaultEncoding ( 'utf8')"src/c_client.py

XFCE4는 카이로, 판고, GTK+등을 컴파일합니다.

  1. XFCE의 컴파일은 XFCE의 전체 크로스 컴파일을 만드는 것과 같습니다. 워크로드는 다양한 구성 요소 간의 순차적 관계와 의존성과 함께 상당히 거대합니다.
  2. 많은 개발 패키지, 시스템 도구 및 개발 패키지에는 이론적으로 소스 코드 컴파일이 필요하며, 이는 큰 워크로드가 있습니다. 개발 패키지 및 시스템 도구에는 버전 요구 사항이 있습니다.
  3. 헤더 파일을 찾지 못하고 공구 경로를 찾지 못하고 XXX에 대한 정의되지 않은 참조와 같은 환경 변수 요구 사항은 환경 변수를 변경하고 매개 변수를 컴파일하려는 다른 시도가 필요합니다.
  4. 컴파일 프로세스 중에는 참조 된 라이브러리의 여러 버전이 있습니다. 사용할 버전을 명확히해야합니다. 편집하는 동안 검색 경로의 우선 순위를 명확히해야합니다.
  5. Meson, G-IR-Scanner, G-IR-Compile 등과 같이 익숙 해야하는 새로운 도구가 많이 있습니다.이 도구는 개발 패키지가 아닌 도구이며 처음 접촉했을 때 이해하지 못했지만 이해하지 못했습니다. 결과적으로, 나는 오랫동안 gobject-introscection을 편집했습니다.
  6. 원형 의존성 컴파일 예를 들면 : 프리 타입 && harfbuzz && cairo는 특정 솔루션을 보려면 mk_xfce.sh 스크립트의 처리를 참조하십시오.

XFCE4의 컴파일, 구성, 설치 및 작동에 대해

이 지식은 비교적 큰 지식을 포함합니다. 해외를 포함하여 중국에서 XFCE4의 편집 및 사용을 구체적으로 소개하는 기사는 상대적으로 적습니다. 나는 또한 돌을 느끼면서 강을 건너이 지식을 명확하게 보여 주려고 노력했다. 나는 이것을 설명하기 위해 특별한 장을 열 것이다. Smart-OS 로의 XFCE4 이식의 경우 그래픽 시스템의 비밀을 중국인에게 드러냅니다. 자세한 내용은 XFCE4.MD를 참조하십시오.

데스크탑 시스템 요약

전체 그래픽 시스템의 통합 워크로드는 시스템의 모든 측면을 포함하여 특히 거대합니다. 해외 에서이 측면에 대한 체계적인 정보는 상대적으로 적고 중국에서는 거의 적습니다. 목표는 전체 그래픽 시스템을 그대로 실행하도록 모든 환경과 개인 오픈 소스 프로젝트를 DIY하는 것입니다. Smart-OS는 첫 번째가 아니지만 기본적으로 상위 3 개입니다. 나는 아직 모른다. 전체 통합 프로세스가 매우 길고 많은 문제가 발생했습니다. 지속적인 디버깅 및 편집을 통해 이러한 반복적 인 작업에 대해 이야기하지 않을 것입니다. 작업량은 특히 거대합니다. 나는 거의 내 일을 열심히 설명 할 수있다. 내 작품을 묘사하는 것은 절대적으로 과장된 것이 아닙니다. 둘째, 나는 많은 지식 포인트를 만났는데, 그 중 다수는 즉시 배우고 팔렸다. 작업 메커니즘을 빠르게 이해하고 문제를 일으킨 다음 문제를 해결해야했습니다. 새로운 학자들이 아이디어를 빠르게 이해하고 시스템 유지 관리에 대한 지침을 제공하며 시스템 문제를 해결하기위한 모델을 제공하는 전반적인 아이디어에 대해 이야기 해 봅시다.

  1. 하드웨어 모듈을 사용할 수 있어야합니다. 그래픽 시스템에는 기본적으로 디스플레이 + 그래픽 카드 + 입력 (키보드, 마우스)이 필요합니다. 이 프로젝트는 기본적으로 VMware 및 QEMU 소프트웨어를 사용하며 소프트웨어에는 다양한 시뮬레이션 하드웨어가 제공됩니다.
  2. 현재 커널은 커널을 지원합니다. 관련 정보를 하나씩 찾아야합니다. 많은 운전자가 필요합니다. 커널을 구성하고 대부분의 커널이 내장 된 커널에 컴파일 할 수 있도록합니다. 자세한 내용은 << 01_build_src.sh >> 커널 구성 파일 교체 Xorg 입력 드라이버, Xorg 비디오 드라이버, Xorg 비디오 가속도 (선택 사항), 일반적으로 사용되는 장치/dev/input/xxx,/dev/dri/xxx 등의 일부를 참조하십시오.
  3. 서비스 계층에서, 우리는 dbus-1, udevd를 사용했습니다. 구성이 올바르지 않으면 Uppower의 관련 부분의 구성 요소가 제대로 작동하지 않으며 Xwindows의 전체 작동에 문제가 있습니다. UDEVD는 제대로 작동하지 않으므로 마우스와 키보드가 제대로 작동하지 않아 인터페이스에 들어간 후 이러한 장치가 정상적으로 작동하지 않습니다. 또한 DBUS 사용자는 생성해야하며 환경 변수를 구성해야합니다.
  4. Xorg 레벨은 키보드 데이터, 스키마, 글꼴 및 기타 기본 데이터를 위해 설치 및 생성되어야합니다. 가장 중요한 것은 Mine Database Desktop의 응용 프로그램에는 해당 데이터의 생성이 필요하다는 것입니다. Xinit은 X 클라이언트와 Xserver를 동시에 끌어 올리는 책임이 있습니다. 물론 쉘에서 수동으로 Xorg를 시작하고 다른 쉘에서 XFCE4- 세션을 시작할 수도 있습니다. 이 모드는 디버깅에 더 편리합니다. 단일 구성 요소의 시작을 디버깅 할 때이 방법에 더 편리합니다.

지식을 확장하십시오

  • USR 디렉토리는 USR = UNIX 시스템 리소스의 약어를 자세히 설명합니다. /lib 라이브러리는 커널 레벨 라이브러리이며, /usr /lib는 시스템 레벨 라이브러리이며 /usr /local /lib는 애플리케이션 수준 라이브러리입니다. /lib에는 /bin && /sbin의 실행 가능한 프로그램에서 사용하는 많은 라이브러리가 포함되어 있습니다. /usr/lib 시스템 실행 프로그램에서 참조하는 거의 모든 라이브러리가 여기에 설치되고/usr/local/bin 애플리케이션 수준 실행 프로그램에서 참조하는 많은 라이브러리가 여기에 배치됩니다.

  • RAMFS :
    RAMFS는 매우 간단한 파일 시스템입니다. Linux 커널의 기존 캐시 메커니즘을 직접 사용합니다 (따라서 구현 코드는 매우 작습니다. 이러한 이유로 RAMFS 기능은 커널 구성 매개 변수를 통해 차단할 수 없습니다. 커널의 자연 속성입니다). 시스템의 실제 메모리를 사용하여 동적 크기의 메모리 기반 파일 시스템을 만듭니다. 시스템은 시스템을 재활용하지 않으며 루트 사용자 만 사용합니다.

  • TMPFS :
    TMPFS는 RAMF의 파생물로 용량 제한을 추가하고 RAMF를 기반으로 스왑에 데이터를 작성할 수 있습니다. 이 두 가지 기능이 추가되어 일반 사용자는 TMPF를 사용할 수도 있습니다. TMPFS는 모든 RAM이 아니라 가상 메모리를 차지하며 성능이 RAMF만큼 높지 않을 수 있습니다.

  • Ramdisk :
    Ramdisk는 메모리의 영역을 물리적 디스크로 사용하는 기술입니다. 또한 Ramdisk는 파일 시스템을 저장하기 위해 메모리에서 생성 된 블록 장치라고도합니다. 사용자의 경우 Ramdisk는 일반적인 하드 디스크 파티션과 동일하게 처리 할 수 ​​있습니다. 이 시스템은 또한 해당 캐시를 메모리에 저장하고 CPU 캐시를 오염시키고 성능이 저하되며 해당 드라이버 지원이 필요합니다.

  • rootfs :
    ROOTFS는 특정 RAMF (또는 TMPFS, TMPFS가 활성화 된 경우)의 인스턴스이며 항상 Linux2.6 시스템에 존재합니다. Rootfs는 제거 할 수 없습니다 (빈 링크 목록을 유지하기 위해 특수 코드를 추가하는 대신 Rootfs 노드를 항상 추가하는 것이 좋습니다. 따라서 커널 유지 관리에 편리합니다. Rootfs는 빈 인스턴스이며 공간이 거의 없습니다). 대부분의 다른 파일 시스템은 rootfs에 설치 된 다음 무시합니다. 루트 파일 시스템의 커널 시작 초기화입니다.

  • 루트는 가상 루프와 실제 루프로 나뉩니다.
    가상 루프는 커널 자체에 의해 생성되고로드되며 메모리에만 존재하며 (후속 initramfs 도이 기준으로 구현 됨) 파일 시스템은 TMPFS 유형 또는 RAMFS 유형입니다.
    실제 rootfs는 루트 파일 시스템이 저장 장치에 존재 함을 의미합니다. 시작 프로세스 중에 커널은이 저장 장치를 가상 루프에 장착 한 다음 / 디렉토리 노드를이 저장 장치로 전환합니다. 이러한 방식으로, 스토리지 장치의 파일 시스템은 루트 파일 시스템 (후속 initramdisk 가이 기준으로 구현됨)으로 사용되며, 파일 시스템 유형은 풍부하여 Ext2, YAFFS, YAFFS2 등이 될 수 있으며 특정 저장 장치의 유형에 따라 결정됩니다.

  • 스타트 업 파일 시스템은 실제로 루프에 대한 파일을 준비하여 커널이 원하는대로 실행할 수 있도록하는 것입니다. 초기 Linux 시스템에서는 하드 디스크 또는 플로피 디스크 만 일반적으로 Linux 루트 파일 시스템의 저장 장치로 사용되었으므로 이러한 장치의 드라이버를 커널에 쉽게 통합 할 수 있습니다. 그러나 오늘날의 임베디드 시스템에서 루트 파일 시스템은 SCSI, SATA, U-DISK 등을 포함한 다양한 스토리지 장치에 저장 될 수 있습니다. 따라서 이러한 장치의 모든 드라이버 코드를 커널에 컴파일하는 것은 분명히 편리하지 않습니다. 커널 모듈 자동로드 메커니즘 UDEV에서 UDEVD는 커널 모듈의 자동로드를 실현할 수 있으므로 루트 파일 시스템을 저장하는 저장 장치의 드라이버가 자동 로딩을 실현할 수 있기를 바랍니다. 그러나 여기에는 모순이 있습니다. UDEVD는 실행 파일입니다. 루트 파일 시스템이 장착되기 전에 UDEVD를 실행하는 것은 불가능합니다. 그러나 UDEVD가 시작되지 않으면 루트 파일 시스템 장치를 저장하는 드라이버를 자동으로로드 할 수 없으며 해당 장치 노드는 /dev 디렉토리에서 설정할 수 없습니다. 이러한 모순을 해결하기 위해 Ramdisk 기반 InitRD (Bootloader 초기 RAM 디스크)가 등장했습니다. InitRD는 압축 된 작은 루트 디렉토리입니다. 이 디렉토리에는 시작 단계에서 필요한 드라이버 모듈, 실행 파일 및 시작 스크립트가 포함되어 있으며 UDEVD (UDEV 메커니즘을 구현하는 악마)도 포함되어 있습니다. 시스템이 시작되면 부트 로더는 InitRD 파일을 메모리로 읽은 다음 메모리의 시작 주소와 크기를 메모리로 전달합니다. 초기화 과정에서 커널은 InitRD 파일을 압축 한 다음 Unipiped InitRD를 루트 디렉토리로 마운트 한 다음 루트 디렉토리에서 /init 스크립트를 실행합니다 (CPIO 형식의 Init는 /init이고 이미지 형식의 initrd는 기존 차단 장치의 InitRD라고도하거나 기존 파일 미러 형식의 초기화)입니다. 이 스크립트에서 InitRD 파일 시스템에서 UDEVD를 실행하고 장치를 저장하기 위해 realFS (실제 파일 시스템) 드라이버를 자동으로로드하고 /DEV 디렉토리에서 필요한 장치 노드를 설정하십시오. UDEVD가 디스크 드라이버를 자동으로로드 한 후 실제 루트 디렉토리를 장착 하고이 루트 디렉토리로 전환 할 수 있습니다.

확장하다
추가 정보
관련 애플리케이션
추천
관련 정보 전체