Get best of the week

Sistem Operasi Sivelkiriya: teknologi

Halo Habr.

Artikel ini melanjutkan serangkaian publikasi tentang proyek sistem operasi Sivelkiriya. Seperti yang telah disebutkan dalam artikel sebelumnya, OS ini saat ini berada pada tahap awal desain dan pengembangan, sehingga mereka yang ingin mendapatkan bukti harus bersabar. Untuk berjaga-jaga, saya akan menyebutkan sekali lagi bahwa penulis tidak bermaksud meyakinkan siapa pun tentang apa pun, alih-alih terus menerbitkan untuk mendapat manfaat dari diskusi. Saya mengambil kesempatan ini untuk mengucapkan terima kasih kepada semua orang yang meninggalkan komentar bermanfaat di bawah publikasi masa lalu.

Artikel pertama dari siklus menyediakan informasi singkat tentang struktur OS ini. Di artikel keduaTujuan dari proyek tersebut dijelaskan, serta bagaimana seharusnya keluar dari lingkaran setan "tidak ada perangkat lunak, tidak ada pengguna, tidak ada pengembang, tidak ada perangkat lunak". Kali ini, fokusnya akan pada masalah arsitektur. Ini akan ditunjukkan dengan apa artinya teknis yang diharapkan untuk memastikan interaksi modul yang ditulis oleh orang yang berbeda dalam bahasa yang berbeda dan berkumpul di bawah lingkungan yang berbeda. Selain itu, detail kecil arsitektur akan terpengaruh.

Penampil Modul


Untuk memastikan pemuatan, peluncuran dan pelaksanaan modul, konsep pemain diperkenalkan di Sivelkiriya. Pelaku itu sendiri adalah modul dan, sehubungan dengan modul yang mereka jalankan, mengambil tanggung jawab berikut:

  1. Mengunduh modul bekas ke dalam RAM, inisialisasi, finalisasi, dan pembongkaran;
  2. Menghubungkan API yang disediakan oleh sistem operasi dengan kode modul yang dapat dieksekusi: memastikan lewatnya panggilan dan data dari API sistem operasi ke kode modul dan sebaliknya;
  3. Unduh dan siapkan lingkungan runtime yang dibutuhkan oleh modul;
  4. Penerjemahan kode modul dari representasi perantara (kode sumber dalam bahasa yang ditafsirkan; kode byte; bahasa perantara; perakitan yang ditujukan untuk platform lain) ke dalam urutan instruksi mesin. Tindakan spesifik pada langkah ini (interpretasi skrip, interpretasi bytecode, kompilasi JIT, emulasi, dll.) Ditentukan oleh metode pengiriman modul;
  5. Menyembunyikan cara kerja modul dari sistem operasi dan modul lainnya.

Selain itu, pelaksana dapat melakukan tugas mengisolasi data dari berbagai modul jika koeksistensi dua atau lebih modul dalam ruang alamat yang sama tidak menimbulkan risiko keamanan (misalnya, untuk kode yang dikelola), dan pekerjaan pelaksana itu sendiri sangat stabil sehingga ada kesalahan dalam pemuatan modul mereka tidak akan menimbulkan masalah dalam pekerjaan kontraktor dan modul lain yang dilayani olehnya.

Konsep ini memungkinkan penggunaan berbagai metode untuk merakit modul dalam sistem umum. Misalnya, kode mesin yang diperoleh dengan mengkompilasi kode C ++ akan dimuat oleh pelaksana yang mendukung eksekusi langsung ke ruang alamat yang terpisah dan dihubungkan dengan lingkungan runtime yang diperlukan. Kode IL yang dikelola dapat dimuat oleh pelaksana yang mendukung pelaksanaan kode yang dikelola, terlebih lagi, isolasi dapat dilakukan baik pada tingkat sistem operasi (dengan memuat berbagai modul dalam ruang alamat yang berbeda) maupun pada tingkat pelaksana (dengan memuat berbagai modul dalam ruang alamat yang sama, tetapi dalam berbagai domain lingkungan).

Pengecualian adalah kasus menjalankan kode mesin di bawah Sivelkiriya, yang dieksekusi sebagai bagian dari sistem operasi utama sebagai satu set perpustakaan dan / atau proses. Menjalankan langsung kode mesin dalam kondisi ini hanya diperbolehkan jika menjamin tidak adanya panggilan dari kode mesin ke sistem operasi utama yang melewati Sivelkiriya, atau jika panggilan tersebut diperlukan dari sudut pandang sistem. Misalnya, kondisi ini dapat dipenuhi dalam lingkungan perusahaan yang terkendali, serta untuk proyek-proyek sumber terbuka. Di sisi lain, modul yang mengakses sumber daya dari sistem operasi utama, menurut definisi, memerlukan cara untuk memanggil fungsinya. Jika "kebersihan" kode mesin tidak dapat dijamin, kode seperti itu dapat dijalankan dalam mode emulasi (dan juga kode yang dikompilasi untuk platform lain).

Jika Sivelkiriya diluncurkan sebagai sistem operasi utama, pemisahan ruang alamat pada level OS dilakukan oleh intinya. Jika dijalankan sebagai satu set pustaka atau proses di bawah sistem operasi utama, untuk memastikan isolasi, modul yang berbeda dapat dimuat ke dalam proses yang berbeda dari OS utama. Modul sistem yang bertanggung jawab untuk pekerjaan langsung dengan peralatan (misalnya, driver sistem file), jika dimulai di bawah sistem operasi utama, akan diganti oleh modul yang meniru perilaku ini, sehingga menyembunyikan perbedaan dari modul aplikasi.

Lingkungan runtime yang disebutkan di atas, khusus untuk bahasa dan kompiler tertentu, adalah yang pertama dari dua pengecualian pada aturan yang mengharuskan pertukaran data antara semua modul hanya melalui antarmuka objek sistem, karena memuatnya ke ruang alamat modul diperlukan untuk operasinya. Konsep pustaka yang terhubung secara dinamis yang digunakan oleh beberapa modul umumnya tidak didukung di Sivelkiriya, karena ini bertujuan untuk mengimplementasikan pembagian kode, yang sudah dilaksanakan melalui antarmuka modul.

Pengecualian kedua adalah izin untuk menggunakan pustaka yang terhubung secara dinamis ke beberapa modul yang dikirimkan bersama dalam paket yang sama. Pada saat yang sama, Sivelkiriya tidak memberikan kesempatan untuk menghubungkan perpustakaan yang sama ke modul lain, serta subsistem untuk mencari perpustakaan dinamis.

Ketika sistem dinyalakan, bagian dari artis dimuat ke dalam memori bersamaan dengan kernel, untuk menghindari situasi ketika artis lain diperlukan untuk memuat artis, yang juga belum dimuat. Ini berlaku, pertama-tama, bagi para eksekutif yang menyediakan peluncuran kode mesin pada platform ini. Pemain yang tersisa dimuat ke dalam memori sesuai dengan aturan umum.

Solusi arsitektur lainnya


Berikut ini adalah daftar singkat prinsip-prinsip sekunder yang tidak terstruktur untuk pembangunan arsitektur OS Sivelkiriya. Mereka tidak sepenting prinsip-prinsip dasar yang diuraikan di atas, tetapi tetap patut disebutkan.

  1. , «». , , , . -, . . , , , , , , . , ; , , Bluetooth, WiFi , Bluetooth, . , (, , , ).
  2. , . , « » « ».
  3. , . , « » « » «». , , .
  4. . , « » ( , , , ), « » . , « », « », ( ) . .
  5. , , , . , , , , . - , , .
  6. ( . .) . , , , - . .
  7. ( ) , «», , , . , , , , .
  8. , , . ( , . .) . . , , .
  9. . , , . — , , , . . , : , ( ) , , .
  10. , : . , .
  11. , , , , — . « » , ( ). , . .
  12. : , , . , , . , , , .
  13. , : , , , , , , , , , . : , , SSD, — RAID- , — , . .
  14. . ( ). , , (, , ), ( ), , , WYSIWYG- , . , .
  15. : , , . , , , ( ). , , , . , , , ( , . .).
  16. , , . , « » , (, 1 ) . , , , : , (, ) , , , , , .
  17. , , (, , ). , — , , , . — (, . .): , , , , . , . , , ( «» ). , . (, ) , ( , . .). , , . , ( , , . .) , .


Publikasi pertama dari siklus tersedia di sini . Yang kedua ada di sini . Yang keempat ada di sini . Teks lengkap artikel tersedia di situs web proyek .

More articles:


All Articles