esque

เล่ห์เหลี่ยม

exokernel ที่ทันสมัย

อาคาร (ใช้ y.py)

esque.toml

ก่อนที่จะพูดถึงระบบบิลด์ที่เขียนด้วยมือฉันต้องพูดถึง esque.toml นี่คือไฟล์การกำหนดค่าที่มีตัวเลือกมากมายสำหรับการปรับแต่ง การตั้งค่านี้ใช้เวลานานมากซึ่งเป็นเหตุผลว่าทำไมตอนนี้จึงเป็นมาตรฐานสำหรับการสร้าง ESQUE OS

การพึ่งพา (บน Linux)

• cargo
• rustc
• dd
• mtools (McOpy, MMD, ... )
• dosfstools (mkfs.vfat)
• python >= 3
• python.toml
• python.xbstrap

ติดตั้ง

$ sudo apt install cargo rustc binutils mtools dosfstools python3 python3-pip ; pip install --user xbstrap toml

อาคาร (บน Linux)

y.py เป็นยูทิลิตี้ที่ได้รับแรงบันดาลใจจาก x.py ของ RustC คุณสามารถกำหนดค่าเคอร์เนลโดยใช้ไฟล์ Esque.toml ที่อาจพบได้ใน sysroot ของไดเรกทอรีนี้ ไฟล์นี้มีตัวเลือกมากมายดูก่อนที่จะสร้าง

คุณสามารถสร้างโครงการได้ง่ายๆ

 ./y.py build

ระบบนี้สามารถกำหนดค่าได้มาก เพียงพิมพ์

 ./y.py --help

เพื่อดูตัวเลือกทั้งหมด

อาคาร (บน windows)

ก่อนอื่นคุณต้องป้อน Esque.toml และเปลี่ยน enable-kvm เป็น false

ไม่แนะนำให้สร้างบนหน้าต่าง ฉันเป็นผู้ใช้ Linux มาเป็นเวลานานและกระบวนการสร้างทั้งหมดได้รับการออกแบบมาสำหรับฉันอย่างไรก็ตามการสร้างโดยใช้ winy.ps1 เป็นไปได้ แต่ยังไม่ได้รับการปรับให้เหมาะสม

บน Windows มีคำสั่ง y.py บางคำเท่านั้นที่สามารถดำเนินการในลักษณะเดียวกับบน Linux (ตัวอย่าง: ./y.py build รัน dd เพื่อสร้างไฟล์ IMG) ดังนั้นคุณจะถูกนำเสนอด้วยสองตัวเลือก

ตัวเลือก A: wsl + native qemu

นี่อาจเป็นตัวเลือกที่ต้องการสำหรับบางคน ในสถานการณ์นี้คุณเรียกใช้คำสั่ง ทั้งหมด ยกเว้น ./y.py run โดยใช้ WSL

สิ่งนี้ต้องการการอ้างอิงทั้งหมดที่ระบุไว้ข้างต้นในส่วน Dependencies (On Linux)

ผู้เชี่ยวชาญ

• เร็ว

ข้อเสีย

• คุณต้องเปลี่ยนเทอร์มินัลทุกครั้งที่คุณต้องการสร้างและเรียกใช้

ตัวเลือก B: ใช้./winy.ps1

winy.ps1 เป็นสคริปต์ PowerShell ซึ่งตัดสินใจว่าจะทำงานอย่างไรและไม่เป็นอะไร การใช้งานเท่ากับ ./y.py เช่น ./winy run วิ่งเคอร์เนลและ ./winy build สร้างบางส่วนของเคอร์เนลโดยใช้ WSL และอื่น ๆ โดยธรรมชาติ

ความสนใจ สิ่งนี้ต้องการให้คุณมีการดำเนินการทางนโยบายของคุณเพื่อบายพาส คุณสามารถเปลี่ยนสิ่งนี้ได้ชั่วคราวโดยการเปิดโฮสต์คำสั่งพร้อมสิทธิ์ของผู้ดูแลระบบและการพิมพ์

 Set-ExecutionPolicy Bypass

สิ่งนี้ต้องการการพึ่งพาทั้งหมดที่ระบุไว้ข้างต้น ยกเว้น การขนส่งสินค้าและ RustC บน WSL มันต้องใช้สินค้า, Rustc และ tar binary บนหน้าต่าง การพึ่งพาดังกล่าวอาจติดตั้งได้อย่างง่ายดายโดยใช้ Rustup Binary rustup.rs

การติดตั้งการอ้างอิงดังกล่าว

เรียกใช้คำสั่งต่อไปนี้บน WSL (สมมติว่า Ubuntu):

$ sudo apt install binutils mtools dosfstools python3 python3-pip ; pip install --user xbstrap toml

ผู้เชี่ยวชาญ

• ใช้งานง่ายมากขึ้น

ข้อเสีย

• wsl-commands มีเวลาเริ่มต้นที่สำคัญ

การพึ่งพาอาศัยกัน

ระบบปฏิบัติการควรอยู่ใกล้กับการพึ่งพาอาศัยกันอย่างปราศจากการพึ่งพา โชคไม่ดีระบบนี้ขึ้นอยู่กับทั้งหมด 2 ลัง:

 bitflags
spin

การพึ่งพาของเรามากกว่า 10 รายการนั้นได้รับการบำรุงรักษาภายใน crates/ ไดเรกทอรีย่อย การพึ่งพาเหล่านี้รวมถึงรถตักน้ำมันและอีกมากมาย

• BitFlags ใช้เพื่อแทนที่ C Bitfields นี่คือการพึ่งพาที่จำเป็น มันถูกใช้ในโครงการหลายพันโครงการทั่วโลก ฉันคิดว่านี่เป็นลังที่ปลอดภัยอย่างสมบูรณ์
• สปินเป็นการทดแทนสำหรับ std::sync::{Mutex,...} นี่เป็นลังที่มีประโยชน์อย่างไม่น่าเชื่อที่ใช้ในโครงการ OSDEV ที่สำคัญเกือบทั้งหมด ลังนี้ อาจ ลดลงในอนาคต

สนิมไม่ก่อให้เกิดไบนารีขนาดใหญ่หรือไม่?

ในขณะที่มันอาจสร้างไบนารีที่ใหญ่กว่าแล้วสมมติว่า c มันยังคงผลิตขนาดเล็กหลังจากลอก เคอร์เนลปัจจุบันมีขนาดประมาณ ~ 300K ซึ่งเป็นที่ยอมรับสำหรับฉัน bootloader มีขนาดใหญ่ประมาณ 270k เนื่องจากการพึ่งพา 'UEFI' ขนาดใหญ่

ปรัชญา

ESQUE เป็นเคอร์เนลที่พยายามรวมเข้าด้วยกันของ Linux และ Windows ในขณะที่เป็นระบบคล้าย exokernel exokernel เป็นเคอร์เนลที่ให้เพียงสิ่งพื้นฐานและสิ่งใด ๆ เพิ่มเติม (เช่นสแต็คเครือข่าย) จะถูกโหลดผ่านโมดูล

ความเข้ากันได้ของ Linux

เนื่องจากความพร้อมใช้งานของซอฟต์แวร์บน Linux ขนาดใหญ่ ESQUE จึงมีความมุ่งมั่นที่จะเข้ากันได้บ้าง มันบรรลุความเข้ากันได้ของระบบไฟล์เนื่องจากการใช้ fake-root มีสองหลัก รากจริง และ รากปลอม ตัวอย่างของ เส้นทางปลอม คือ /home/user/ หรือ /bin/* เส้นทาง รูทจริง เริ่มต้นด้วย อุปกรณ์: รูปแบบเส้นทาง ตัวอย่าง: initramfs:/myfile , C:/Binaries/* , B:/BOOT/EFI/BOOTX64.EFI , C:/Users/User/ หรือ proc:/CpuInfo

Linux Syscalls ตั้งอยู่ที่ตำแหน่งจริง (0, 1, 2, 3, 4 ... ) ในขณะที่ ESQUE Syscalls อยู่ที่ (SYS_NUM + 0x1000)

ทุกอย่างทำงานใน Userspace หรือไม่?

ใช่ - และไม่ใช่ ใน ESQUE มี 'ช่องว่าง' เสมือนจริง สามช่องสำหรับแอปพลิเคชัน มีเพียงสองคนเท่านั้นที่เป็นของจริง มี

• พื้นที่เคอร์เนล ( เฉพาะเคอร์เนล - สามารถเข้าถึงฮาร์ดแวร์อาร์เรย์เต็มรูปแบบ)
• พื้นที่ระบบ ( ไดรเวอร์ - ทำงานในพื้นที่เคอร์เนลของ CPU มีการเข้าถึง IPC ด้วยเคอร์เนลและ HAL (HAL = ชั้นนามธรรมฮาร์ดแวร์)
• พื้นที่ผู้ใช้ ( แอปพลิเคชัน - สามารถเข้าถึงการโทรของระบบเท่านั้น)

การบริจาค

ฉันเข้าใจว่ามีคนไม่มากที่เต็มใจที่จะใช้เวลากับเคอร์เนลเช่นนี้ ฉันจะยังคงยินดีต้อนรับการมีส่วนร่วมใด ๆ ไม่ว่าจะเล็กหรือใหญ่แค่ไหน โปรดอ่านไฟล์การมีส่วนร่วมและดูไฟล์ในไดเรกทอรีเอกสาร

initramfs

ใน initramfs ณ ตอนนี้ยังไม่มีการสนับสนุนไดเรกทอรี คุณสามารถสร้าง initRAMFS ใหม่ได้เพียงแค่ใส่ไฟล์ลงใน initramfs/ SubDirectory จากนั้นใช้ ./y.py initramfs initramfs ที่เสร็จแล้วจะพบใน build/initramfs.tar bootloader คาดว่าไฟล์นี้จะพบได้ในพาร์ติชันรูท

ไฟล์ทั้งหมดที่ลงท้ายด้วย .system จะถูกโหลดโดย initramfs คาดว่าไฟล์ใด .system หนึ่งไฟล์ดังกล่าวจะโหลดระบบไฟล์

เกี่ยวกับความไม่ปลอดภัย

ในขณะที่มันเป็นความจริงที่ระบบปฏิบัติการที่ไม่มีรหัสที่ไม่ปลอดภัยเป็นไปไม่ได้ แต่ฉันพยายาม จำกัด มันไว้ที่นี่ ณ จุดใด

 ./y.py count-unsafe

อาจถูกเรียกใช้ซึ่งจะแสดงข้อมูลเกี่ยวกับความไม่ปลอดภัยของรหัส ในช่วงเวลาของการเขียนผลลัพธ์ต่อไปนี้จะถูกสร้างขึ้น:

 A total of 52 occurences have been found (1641 LOC, 0.* percent Percent)

แผนงาน

• bootloader ของตัวเอง
• การโหลดแบบอักษร
• GDT
• idt
• ข้อบกพร่องทั้งหมดจัดการ
• พอร์ตโออิโอ
• ไดรเวอร์ทางเลือกสำหรับ Shall-shell (เพื่อจุดประสงค์ในการดีบัก)
• ระดับ 4 เพจ
• แป้นพิมพ์ PS2
• ลังเลย์เอาต์คีย์บอร์ด
• การสนับสนุนเมาส์ PS2
• การจัดสรรหน่วยความจำ
• โหลดไฟล์ tar
• สนับสนุน Crate alloc
• การแมปตารางหน้าใหม่
• Syscalls
• IPC-messaging
• ตัวอธิบายอุปกรณ์ PCI
• ผู้ดำเนินการ
• กอง
• แอปพลิเคชันพื้นที่ระบบโหลด
• โหลด initramfs
• การทำงานหลายอย่าง
• จบไดรเวอร์ ext2
• การเปิดตัวครั้งสำคัญ 1
• ACPI
• ตัวชี้ RSDP
• รถบัส PCI
• การระบุ PCI
• การสนับสนุน PIC เต็มรูปแบบ
• อีกมากมาย ...