Wykład OS - Systemy Operacyjne PDF

Document Details

SelfSufficiencyRuthenium6360

Uploaded by SelfSufficiencyRuthenium6360

Wrocław University of Science and Technology

Tags

systemy operacyjne programowanie komputery mikroprocesory

Summary

Ten dokument przedstawia wprowadzenie do systemów operacyjnych, opisując różne typy systemów, ich funkcje oraz zastosowania. Zawiera informacje na temat warstwy abstrakcyjnej, zarządzania zasobami, wielozadaniowości, oraz różnych rodzajów systemów operacyjnych i ich możliwości technicznych. Szczególną uwagę poświęca się programowaniu sprzętu, w tym mikrokontrolerów i wykorzystywania narzędzi programistycznych.

Full Transcript

W1 Systemy operacyjne Kol 1 – 14.01.25 Kol 2 (drugi termin) – 05.02.25 W2 Wprowadzenie do systemów operacyjnych Co to jest system operacyjny?...

W1 Systemy operacyjne Kol 1 – 14.01.25 Kol 2 (drugi termin) – 05.02.25 W2 Wprowadzenie do systemów operacyjnych Co to jest system operacyjny? “An elephant is a mouse with an Operating System.” Donald Ervin Knuth – creator of the TeX computer typesetting system, author of “The Art of Computer Programming” Problem numer 1: programiści pracowali nad podobnymi problemami w swoim oprogramowaniu - opracowywanie danych wejściowych - formatowanie wyjść - współpraca z popularnymi urządzeniami (terminale, urządzenia gromadzące dane) - przetwarzanie typowych danych - oprogramowanie interfejsów użytkownika Jak poprawić efektywność programistów i jakość kodu: - można powtarzać te czynności i robić je samemu albo - użyć zewnętrznych wysokopoziomowych sterowników i bibliotek Problem numer 2: powolne i nieefektywne procesy I/O vs szybkie i drogie CPU marnujące czas w oczekiwaniu na dane Wczesne rozwiązania: Program nie zawiera już czystego kodu ale zawiera biblioteki z funkcjami współdzieli operacje I/O, które są oddzielone od samego procesu przetwarzania danych Jednakże cały komputer dalej należy do jednego użytkownika. Program używa raczej uporządkowanych bibliotek w trakcie działania niż skompilowanych w kodzie programu. To wprowadziło dodatkową warstwę między użytkownika i sprzęt. Monitory, kolejki, dzielenie systemu Jeśli wielu użytkowników chciało używać jednego komputera w tym samym czasie potrzebne było generowanie sygnału gdy dany program został zakończony aby załadować i uruchomić następny (z taśmy magnetycznej lub papierowej). Ludzki operator działa wolniej niż specjalny dedykowany automatyczny proces (hardware/software). Początek epoki OS Systemy operacyjne pogrupowane wg wielkości, funkcjonalności i aplikacji superkomputery, mainframes i systemy rozproszone Supercomputers, mainframes and distributed systems: scientific computing, numerical modeling (i.e. climate or nuclear weapons), search engines historical example: IBM's System/360; currently: IBM's z/VSE (Virtual Storage Extended) servery Servers OS: Internet and intranet services, such as WWW, FTP, databases, DNS, VPN, applications. Single machines, server farms, distributed servers, virtualization and combinations of above configurations are widely used desktopy Desktops OS: computers designed mainly to be used by one operator at a time, Human-Machine Interface (GUI) is very important part of the whole system. Examples: Windows XP, Windows 11, Mac OS, Ubuntu… handhelds (smartfony, tablety, PDA,...) Operating systems for mobile devices: power-efficient, handheld devices, OS designed to operate on less capable devices. Examples: PalmOS, Symbian, Android, Windows Mobile, Windows CE, Windows 10, iOS systemy czasu rzeczywistego (real-time - RTOS) Real-time operating systems: designed to respond within specified time (seconds, milliseconds or even microseconds). Applications: spacecrafts, automobile controllers, industrial applications... Examples: QNX, Windows CE, FreeRTOS, RTLinux wbudowane (embedded) (ATM, samochodowe,...) Embedded OS: operating system is an integral part of the device, starting from ignition system on cars, smart sensors, up to portable devices. Examples: FreeBSD, QNX, Windows CE, Linux, Symbian, Android Co to jest system operacyjny? ❖ Warstwa abstrakcyjna (zestaw warstw) oddzielająca użytkownika od sprzętu ❖ Manager komputerowych możliwości (CPU, pamięć, urządzenia zewnętrzne) ❖ Wirtualna platforma dla wysokopoziomowych aplikacji ❖ Sposób wprowadzenia wielozadaniowości nawet jeśli fizycznie jest tylko jeden mikroprocesor ❖ Sposób na zredukowanie kosztów opracowania nowych programów gdy nowy sprzęt pojawia się na rynku ❖ Dodatkowo: standaryzacja CLI/GUI HAL - hardware abstraction layer System operacyjny dla jednego mikrokontrolera? Mikrokontrolery często są oprogramowane bez systemu operacyjnego – aplikacja przejmuje całkowitą kontrolę nad urządzeniem ale… Są systemy operacyjne dla tego typu urządzeń, w szczególności systemy operacyjne czasu rzeczywistego (RTOS). Zaletą takiego rozwiązania jest praca w dobrze przetestowanym środowisku i możliwość wykorzystania mechanizmu przełączającego zadania. „Kompaktowa” uproszczona wersja SO pracująca na jednoukładowym mikrokontrolerze. Często nazywana Wbudowanym Systemem Operacyjnym. A co z urządzeniami „smart”? Szybki rozwój rynku urządzeń, które możemy ulokować między komputerami stacjonarnymi a prostymi mikrokontrolerami : Smartfony, PDA, Tablety, Netbooki, Czytniki Ebooków, Domowe i samochodowe „centra rozrywki”, „Mądre” czujniki, wyposażenie domu. Te wszystkie urządzenia wykorzystują efektywne i relatywnie tanie mikroprocesory, idealne dla mobilnych aplikacji. Ale można na nich używać zarówno wbudowanych systemów operacyjnych jak i SO z komputerów stacjonarnych. PDA, G1, BeagleBoard Łączy ich: podobny hardware (1 GHz procesor, 256-512 MB RAM, interfejsy internetu, USB i wideo), wszystkie dostarczone z preinstalowanym SO chociaż zupełnie różnym: PDF – Windows Mobile 5.0, G1 – Android 1.6, BeagleBoard – uproszczona wersja Linuxa Środowisko programowe dla PDA Microsoft Visual Studio 2022 Windows CE Toolkit Nowe platformy (WM 5, WM 6) wymagają C# and.NET Bardzo proste w użyciu vs instalacja Podobne do desktopowego (WinAPI-like or.NET-like) programowania Koszt! …albo można użyć MSDN AA Wbudowane emulatory różnych urządzeń (PDAs i SmartPhones) Bardzo proste poprawianie błędów programów albo poprzez emulator albo przez połączenie złączem USB → Środowisko programowe dla urządzeń z Androidem Darmowe Android Studio IDE Darmowe Android SDK Wbudowane emulatory różnych urządzeń (można stworzyć własne) Łatwe debugowanie aplikacji w emulatorze jak i na podłączonym urządzeniu (wifi, USB) Łatwe w instalacji Java/Kotlin programming language Dobrze udokumentowane SDK IDE - Integrated Development Environment SDK - Software Development Kit BeagleBoard xM IMX53QSB (Freescale -> NXP) Raspberry PI 3 model B - Variety of operating system - Variety of operating system - Variety of operating system ports, including many Linux ports, including many Linux ports, including many Linux distributions, QNX, distributions, Windows7 distributions, Windows7 Windows CE, Android, mobile, Android, … mobile, Android, … Symbian, XBMC Media - Code development - Code development Center, … environment depends on environment depends on - Code development system chosen system chosen environment depends on - No Flash memory, no risk of - No Flash memory, no risk of system chosen destroying bootloader, destroying bootloader, - No Flash memory, no risk of system boots directly from system boots directly from destroying bootloader, microSD card microSD card system boots directly from - 1 GHz CPU, 1 GiB of - 4x1.4 GHz CPU, 1 GiB of microSD card RAM, GPU for media RAM, GPU for media - 1 GHz CPU, 512 MiB of processing, 2D/3D capable processing, 2D/3D capable RAM, DSP for media graphics controller,… graphics controller,… processing, 2D/3D capable - low-cost solution (only - low-cost solution (only ~200 graphics controller,… $149), zł), - Relatively low-cost solution - 2 x USB, VGA, RS232, - 4 x USB, HDMI, (only $179), well-suited for FastEthernet FastEthernet class-lab or hobbyists - Optional touch-screen - Optional touch-screen Wirtualizacja vs rzeczywisty komputer Można instalować i konfigurować wiele systemów operacyjnych na jednym komputerze w tym samym czasie; Nie ma niebezpieczeństwa utraty danych z powodu błędnego działania; Możliwe jest zatrzymanie a następnie kontynuowanie pracy w dowolnym czasie; Na jednym komputerze można uruchomić wiele „komputerów” w tle a jednocześnie nie tracić parametrów rzeczywistego komputera; W trakcie eksperymentów z różnymi systemami właściwy system operacyjny komputera jest cały czas dostępny. o You can setup as many virtual machines as you need o Machines can be run simultaneously o Hardware support for virtualization can be enabled o Host’s NIC can be bridged giving direct access to the networkto the guest OS o Some USB devices can be accessed by the guest OS o You can copy whole virtual disk image to pen drive and use it virtually anywhere Programowanie – ANSI C Oba systemy są zainstalowane na wirtualnej maszynie; Większość dystrybucji Linuxa jest dostarczana z kompilatorem gcc; Windows wymaga zainstalowania środowiska, dostępne są w dużych ilościach np. Visual Studio; Dobrze zaprojektowane kompilatory C są dostępne dla wielu platform; printf() jest funkcją biblioteczną – wywołuje funkcję systemową. Rezultat jest identyczny na Windows 10/11 (64- bit) (Windows XP – 32-bit) jak i na Linux Debian (64-bit). W obu przypadkach zobaczymy ”Hello, world!”. ANSI C – plusy i minusy Dostępny dla większości albo i wszystkich platform na Świecie De facto standard w UNIXie i Linuxie Język wysokiego poziomu, ale bardzo szybki i elastyczny Dostępne są miliardy linii kodu źródłowego za darmo Większość kerneli SO jest napisana w C ale: Nie-intuicyjna składnia Wskaźniki mogą być przekleństwem dla programisty (przepełnienia buforów, braki pamięci, …) Zależny od architektury (8-,16-,32-,64-bit, kolejność bajtów, przesunięcie struktury, …) W3 Dlaczego potrzebujemy systemy operacyjne Czy naprawdę potrzebny jest system operacyjny? Spróbujmy zaprogramować mikrokontroler bez żadnego systemu operacyjnego: Kontroler – środowisko programistyczne Pierwsze podejście – mrugające diody Drugie podejście – użycie timerów, przerwań, programowanie terminalem Trzecie podejście – niezależne timery do wielu LEDów Czwarte podejście – RTOS, stos TCP, TELNET, HTTP… możliwość sterowania Systemy operacyjne czasu rzeczywistego (RTOS) Hardware (𝝁𝑪) – krótkie wprowadzenie Port – urządzenie I/O, często fizyczny pin. Może być konfigurowany jako wejście, wyjście lub dwukierunkowy. Zapisanie danych (kombinacja bitów) oznacza ustawienie pinu w stan „wysoki” lub „niski” co oznacza napięcie na pinie lub jego brak. W języku C port może być dostępny jako zmienna. Timer – (zegar) urządzenie wewnątrz μC, które może służyć do wywoływania przerwań co określony czas. Interrupt – (przerwanie) zdarzenie które powoduje zatrzymanie (μC) wykonywanego programu i wykonanie podprogramu związanego z danym przerwaniem – interrupt subroutine (ISR). Właściwości przerwania zależą od priorytetów, masek i sprzętowych rozwiązań. UART – sprzęt (złącze) który może być użyty do wymiany danych (np. znaków z klawiatury) między μC i innymi urządzeniami. W komputerach stacjonarnych może to być RS232 lub konwerter USB-RS232. ProcessorExpert i CodeWarrior - CW + PE – łatwe użycie MCU - Większość konfiguracji odbywa się auto-magicznie – GUI (PE) - Kod dla CPU inicjalizacja ustawienie peryferii generowane jest „w locie”- Najważniejsze to wybór zegara i ustawienie częstotliwości. Później co najmniej najszybszy mod wymaga konfiguracji, domyślne ustawienia są akceptowalne. ProcessorExpert: UART Historycznie, tradycyjną drogą połączenia człowiek-maszyna był terminal tekstowy. Można tego łatwo dokonać przez UART. Możemy wysyłać dane, znak po znaku, i zapisywać w specjalnym rejestrze a następnie odczytywać podprogramem z przerwania. Podobnie do shella ale bez edytora czy wild characters. Składnia komend jest również bardzo prosta. Mrugające diody – podejście pierwsze - 4 LEDy są podłączone do pinów PORTLD; - Sterowanie LEDami jako 4-bitowym wektorem (nie niezależnymi bitami); - Piny LEDów są wyjściami; - Dostępne metody dla tych komponentów: LED_PutVal(…), LED_NegBit(…), … - Funkcja Sleep(ms) stosowana do czekania (w ms), proste mruganie LED2 może wyglądać następująco: Jak można mrugać różnymi LEDami niezależnie, z różnymi częstotliwościami w tym samym czasie? 1. Podejście z użyciem wielowątkowości W systemach z obsługą wielowątkowości (np. Raspberry Pi z Pythonem lub mikrokontrolery z RTOS) można stworzyć osobny wątek lub zadanie dla każdej diody LED. Każdy wątek będzie odpowiedzialny za sterowanie swoją diodą z określoną częstotliwością. 2. Podejście z harmonogramem (Scheduler) W systemach z ograniczoną pamięcią, np. na mikrokontrolerach, można użyć prostego harmonogramu czasu rzeczywistego (czasem wbudowanego w system RTOS) lub napisać własny. 3. Podejście z timerami sprzętowymi W mikrokontrolerach (np. Arduino, STM32) można użyć sprzętowych timerów do obsługi niezależnych mrugnięć. Każdy timer może być skonfigurowany z inną częstotliwością. Timer i przerwanie – podejście drugie Dodajemy następny komponent (bean): Timer (PIT0) → TimerInt, nazwijmy go TI1. Ustawmy wstępnie okres przerwania na 100ms. Wejdźmy do pliku źródłowego Events.c i dodajmy następujące linie kodu: Wiele timerów i przerwań – podejście trzecie Dodajmy kolejny timer TI2 z częstotliwością mrugania 44ms LED3 w kolejnej funkcji event-handler. Przełączmy na ‘expert view’ aby otrzymać dostęp do ustawień priorytetów timerów przerwań. Czy to jest prawdziwy multitasking? Nie, to nie jest prawdziwy multitasking w rozumieniu równoczesnego wykonywania wielu zadań. W przypadku mikrokontrolerów i przerwań mamy do czynienia z współbieżnością. Timer i inne funkcje przerwań działają sekwencyjnie, a nie równocześnie – procesor obsługuje tylko jedno przerwanie na raz. Jednak szybkie przełączanie między przerwaniami może symulować równoległość. W kontekście systemów wbudowanych i ogólnie systemów operacyjnych, multitasking oznacza zdolność do jednoczesnego (lub pozornie jednoczesnego) wykonywania wielu zadań przez procesor. Multitasking to sposób zarządzania czasem procesora, który pozwala wykonywać wiele zadań (procesów lub wątków) jednocześnie, poprzez ich szybkie przełączanie. Procesor fizycznie wykonuje tylko jedno zadanie w danym momencie, ale dzięki odpowiedniemu harmonogramowi tworzy iluzję równoczesności. Rodzaje multitaskingu: 1. Kooperacyjny multitasking: Zadania same decydują, kiedy zwolnić procesor (np. w systemach bez RTOS). Jest to mniej niezawodne, ponieważ jedno zadanie może monopolizować procesor. 2. Wymuszony multitasking (preemptive multitasking): System operacyjny (lub RTOS) wymusza przełączanie zadań w ustalonych momentach, na przykład na podstawie przerwań sprzętowych, timerów lub priorytetów. Cechy multitaskingu: - Procesor dzieli czas między różne zadania. - System może reagować na różne zdarzenia (np. przerwania) równolegle. - Zadania mogą mieć różne priorytety, co umożliwia obsługę krytycznych operacji w pierwszej kolejności. W systemach wbudowanych multitasking ma kilka specyficznych cech: 1. Multitasking sprzętowy: - Mikrokontrolery nie mają wielu rdzeni, więc prawdziwy równoległy multitasking nie istnieje (chyba że procesor ma więcej rdzeni). - Timer, przerwania i pętla główna symulują multitasking poprzez szybkie przełączanie między zadaniami. 2. Multitasking w systemie RTOS: - RTOS (Real-Time Operating System) zapewnia preemptive multitasking, gdzie zadania są wykonywane zgodnie z harmonogramem priorytetowym. - Każde zadanie ma swój czas i zasoby, co pozwala na bardziej kontrolowane zarządzanie. 3. Multitasking a przerwania: każde przerwanie działa jako osobny blok kodu, który jest wywoływany, gdy wystąpi zdarzenie (np. timer osiągnie określoną wartość). Nie jest to multitasking w pełnym tego słowa znaczeniu, ponieważ każde przerwanie jest wykonywane w całości przed rozpoczęciem kolejnego (o ile nie zostanie przerwane przez inne o wyższym priorytecie). Nie istnieje tu równoczesne wykonywanie zadań – jest to raczej priorytetyzowana obsługa zdarzeń. Co się stanie jeśli jeden event-handlers zawiesi się? Jeżeli jeden z obsługiwaczy przerwań się zawiesi: Procesor pozostanie w tej funkcji, dopóki się nie zakończy, blokując obsługę innych przerwań. Żadne inne przerwanie (nawet o wyższym priorytecie) nie będzie mogło być obsłużone, jeśli mechanizm przerwań nie jest poprawnie skonfigurowany. Cały system może przestać działać zgodnie z założeniami, powodując tzw. starvation (głodzenie) innych zadań. Aby temu zapobiec, można: Wprowadzić limity czasowe w obsłudze przerwań. Zminimalizować ilość pracy wykonywanej w obsłudze przerwań (np. delegować ciężkie zadania do pętli głównej). Użyć systemu RTOS, który pozwala na monitorowanie czasu obsługi zadań. W systemach wbudowanych, gdy event-handler (czyli funkcja obsługująca przerwanie) się zawiesi, mogą wystąpić następujące problemy: a) Blokada innych przerwań Bez preempcji (przerwania nie mogą przerywać siebie nawzajem): o Jeśli event-handler trwa zbyt długo (lub w ogóle się nie kończy, np. z powodu pętli nieskończonej), inne przerwania nie będą mogły zostać obsłużone, nawet jeśli wystąpią. o Cały system "zamiera", ponieważ procesor nie powraca do pętli głównej ani nie obsługuje innych zdarzeń. Z preempcją (przerwania o wyższym priorytecie mogą przerywać te o niższym priorytecie): o Jeśli event-handler o niskim priorytecie się zawiesi, procesor nadal może obsłużyć przerwania o wyższym priorytecie. o Jednak funkcja pętli głównej lub inne zadania systemowe mogą zostać zablokowane, ponieważ procesor stale przełącza się między przerwaniem zawieszonym a innymi przerwaniami, ignorując resztę kodu. b) Przepełnienie stosu Każde przerwanie powoduje zapisanie kontekstu (stan rejestrów i inne dane) na stosie. Jeśli funkcja obsługi przerwania się zawiesi, procesor może: Nie zwolnić stosu, co powoduje jego przepełnienie, szczególnie jeśli występują kolejne przerwania lub funkcje. W rezultacie system może się zawiesić lub zacząć działać nieprzewidywalnie. c) Problemy z czasem rzeczywistym Systemy wbudowane często mają wymagania czasu rzeczywistego (real-time). Jeśli jedno przerwanie zajmuje zbyt dużo czasu lub zawiesza się: Opóźnia inne przerwania, powodując naruszenie założeń czasowych. Na przykład, jeśli jedno z przerwań obsługuje diodę LED z częstotliwością 44 ms, zawieszenie innego przerwania może spowodować brak synchronizacji lub zbyt wolne miganie. d) Przykłady przyczyn zawieszania się event-handlera: 1. Pętla nieskończona w funkcji obsługującej przerwanie 2. Nadmiar operacji w przerwaniu: o Wykonywanie złożonych obliczeń, operacji I/O lub oczekiwanie na inne zdarzenia w funkcji obsługującej przerwanie. o Zasada: Funkcja obsługi przerwania powinna być jak najkrótsza i wykonywać jedynie krytyczne operacje. Jak zapobiegać zawieszaniu się? 1. Minimalizować pracę w obsłudze przerwań: o Przerwanie powinno ustawiać tylko flagę lub wykonywać proste operacje. Więcej pracy można przenieść do pętli głównej lub zadania RTOS. 2. Monitorowanie czasu w przerwaniu: o Użyć mechanizmu watchdog timer, aby wykryć zawieszenie procesora lub przerwania. 3. Użycie RTOS z limitem czasu dla zadań: o System RTOS może wymuszać przełączenie zadań po określonym czasie. Jaki wpływ na właściwości mają priorytety przerwań? Priorytety przerwań wpływają na to, które przerwanie zostanie obsłużone jako pierwsze w sytuacji, gdy dwa lub więcej przerwań wystąpią w tym samym czasie. Kluczowe punkty: Wyższy priorytet: Przerwania o wyższym priorytecie mogą przerywać obsługę przerwań o niższym priorytecie. Niższy priorytet: Przerwania o niższym priorytecie muszą czekać na zakończenie obsługi przerwań o wyższym priorytecie. Priorytety pozwalają nadać ważniejszym zadaniom większą responsywność. Niewłaściwe skonfigurowanie priorytetów może prowadzić do zjawiska priorytetowego inwersji, gdzie zadania o niskim priorytecie blokują zadania o wysokim priorytecie. Priorytety przerwań mają kluczowe znaczenie w systemach wbudowanych. Określają, które przerwanie zostanie obsłużone jako pierwsze w sytuacji konfliktu (gdy kilka przerwań wystąpi jednocześnie lub w krótkim odstępie czasu). a) Priorytety przerwań – jak działają? Każde przerwanie w systemie może mieć przypisany priorytet. Gdy dwa przerwania wystąpią jednocześnie: o Przerwanie o wyższym priorytecie zostanie obsłużone jako pierwsze. o Przerwanie o niższym priorytecie musi poczekać, aż przerwanie o wyższym priorytecie zakończy działanie. W niektórych mikrokontrolerach możliwe jest również preemptowanie (przerywanie) przerwania niższego priorytetu przez wyższy priorytet. Dzięki temu krytyczne zadania mogą być obsługiwane natychmiast. b) Właściwości i wpływ priorytetów: 1. Responsywność systemu: o Przerwania o wyższych priorytetach mogą zostać obsłużone szybciej, co jest kluczowe w systemach czasu rzeczywistego. o Np. przerwanie obsługujące komunikację (UART) może mieć wyższy priorytet niż mruganie LED, aby nie tracić danych. 2. Opóźnienia (latency): o Przerwania o niższym priorytecie mogą być opóźnione, jeśli procesor jest zajęty obsługą przerwania o wyższym priorytecie. o Zbyt duża różnica w priorytetach może prowadzić do problemu głodzenia zadań (ang. starvation). 3. Współdziałanie wielu przerwań: System działa efektywnie tylko wtedy, gdy priorytety są odpowiednio dobrane. Priorytety powinny odzwierciedlać krytyczność zadań: Wyższy priorytet dla zadań wymagających szybkiej reakcji (np. obsługa czujników czasu rzeczywistego). Niższy priorytet dla zadań mniej istotnych (np. sterowanie diodami LED). 4. Martwy punkt (Deadlock): Nieprawidłowa konfiguracja priorytetów może prowadzić do sytuacji, w której przerwanie niższego priorytetu blokuje wyższe zadanie, np. gdy zasoby są współdzielone przez przerwania. c) Jak konfigurować priorytety przerwań? 1. Analiza krytyczności zadań: o Najwyższy priorytet dla zadań czasowo krytycznych (np. kontrola silnika, komunikacja). o Niższy priorytet dla zadań niewymagających szybkiej reakcji (np. sterowanie diodami LED). 2. Unikanie priorytetowego inwersji: Priorytetowy inwersja występuje, gdy zadanie o wysokim priorytecie musi czekać na niższy priorytet (np. współdzielony zasób). Rozwiązaniem może być protokół dziedziczenia priorytetu (ang. priority inheritance). 3. Testowanie systemu: Należy dokładnie przetestować konfigurację przerwań, aby upewnić się, że system działa zgodnie z oczekiwaniami. Timery i przerwania: za i przeciw Za: Początkowo wygląda bardzo prosto Każde zadanie działa niezależnie od innych Rozwiązanie jest wspomagane sprzętowo Przeciw: Ograniczone zasoby (timery, poziomy priorytetów przerwań) Ciężko znaleźć warunki wyścigu w całym kodzie przed uruchomieniem programu Sprawa się komplikuje jeśli zadania muszą wymieniać dane Jak ustaliliśmy wcześniej – zaczęliśmy źle! Nasze rozwiązanie jest zależne od sprzętu, nawet jeśli zmienimy tylko jeden bit w konfiguracji; Przeportowanie kodu na inny CPU zajmuje bardzo dużo czasu, należy zmienić sprzętową część kodu (większość kodu); Rozwiązanie przypominające multitasking jest możliwe ale nieprzewidywalne. A nawet nie zaczęliśmy myśleć o bardziej skomplikowanych rzeczach: stos TCP, WWW server, … Sprawy jeszcze bardziej się komplikują jeśli mamy ograniczone zasoby (przerwania, poziomy priorytetów, …). Rozwiązanie przypominające SO: RTOS ze stosem InterNiche TCP Darmowe ze sprzętem Freescale; Źródła w kodzie C, mogą być modyfikowane przez użytkownika; Wspomaganie wielu procesorów; Mały kod wynikowy (mniej niż 50 KiB) i małe wymagania RAM (wystarczy ok. 20 KiB); Darmowa wersja CodeWarrior 7.x jako IDE; Dodatkowo: stos TCP, HTTP server, konsola tekstowa, UDP i TCP; Użytkownik musi tylko dodać własne zadanie (co ciekawe, zadanie mrugających LEDów już jest dodane ☺). Mrugające diody – podejście czwarte Podstawowe parametry zadania są umieszczone w inet_taskinfo struktury C, takie jak wielkość stosu i wskaźnik do funkcji zadania. Każde zadanie potrzebuje osobnej struktury oraz ‘task object’. Ta część kodu jest stworzeniem zadania co typowo jest robione po starcie systemu w funkcji main(). Potrzebujemy również funkcji wykonującej zadanie. Każda taka funkcja składa się z nieskończonej pętli. Funkcja tk_sleep (ticks) musi być wywoływana okresowo do przełączania zadań. 1 tick = 1 ms, w tym przykładzie LED3 zmienia stan co 999 ms. System czasu rzeczywistego (ang. Real-Time System – RTS) to urządzenie techniczne, którego wynik i efekt działania jest zależny od chwili wypracowania tego wyniku. Funkcja zysku jest funkcją zależną przede wszystkim od czasu i określa korzyść ze zrealizowania zadania przez system. Te wykresy ilustrują sposób, w jaki różne rodzaje tych systemów reagują na czas wykonania zadań. Chodzi o to, jak ważne jest ukończenie zadania w określonym czasie i jakie są konsekwencje, gdy to się nie uda. Co to są systemy czasu rzeczywistego (real-time systems)? System czasu rzeczywistego to taki system, który musi wykonać swoje zadania w określonym czasie, zgodnie z wymaganiami czasowymi. Kluczową cechą jest to, że czas wykonania zadania ma znaczenie, a nie tylko samo wykonanie. Deadline (𝑡𝑇 ): To moment, w którym zadanie musi być ukończone, aby było użyteczne. Te koncepcje są kluczowe w projektowaniu systemów komputerowych, które muszą reagować na zdarzenia w określonych ramach czasowych. Dzięki temu możemy: 1. Zrozumieć wymagania czasowe różnych systemów - Nie wszystkie systemy mają tak samo rygorystyczne wymagania czasowe. W niektórych systemach nieukończenie zadania na czas może mieć katastrofalne skutki, a w innych – tylko zmniejszyć efektywność. 2. Projektować systemy odpowiednie dla danej aplikacji - W zależności od typu systemu (Hard, Firm, Soft Real-Time) określamy, jak krytyczne są terminy realizacji. Dzięki temu możemy wybrać odpowiednie metody sterowania, harmonogramowania zadań i alokacji zasobów. 3. Zoptymalizować działanie systemu - W systemach o łagodniejszych wymaganiach czasowych (Soft Real-Time) można lepiej gospodarować zasobami, bez potrzeby rygorystycznego przestrzegania terminów. Hard Real-Time Systems Nie można się spóźnić. Jeśli system nie zakończy zadania przed deadline'em (t_T), skutki mogą być katastrofalne. Przykład: o Sterowanie autopilotem w samolocie – każda reakcja na zmiany w otoczeniu musi być natychmiastowa, bo spóźnienie mogłoby spowodować wypadek. o System medyczny sterujący urządzeniami podtrzymującymi życie – opóźnienie może zagrozić zdrowiu lub życiu pacjenta. Firm Real-Time Systems Nie można się spóźnić, ale to nie koniec świata. Zadanie musi być ukończone przed deadline'em, bo inaczej jego wynik staje się bezużyteczny, ale system może działać dalej. Przykład: o System transakcji giełdowych – jeżeli transakcja zostanie zrealizowana po deadline'ie, jest bezwartościowa, bo ceny akcji już się zmieniły. o Multimedialne systemy przetwarzania danych – np. transmisja wideo, gdzie brak pakietu danych po określonym czasie powoduje utratę synchronizacji. Soft Real-Time Systems Znaczenie: Spóźnienie jest akceptowalne, ale pogarsza jakość. Zadanie wykonane po deadline'ie może być nadal użyteczne, ale jakość systemu stopniowo maleje wraz z opóźnieniem. Przykład: o Gry komputerowe – jeśli opóźnienia w reakcji gracza wynoszą kilka milisekund, gra nadal działa, ale może być mniej responsywna. o Strumieniowanie wideo – jeśli pakiety danych docierają z opóźnieniem, może dojść do utraty klatek, co obniża jakość obrazu, ale odtwarzanie nadal działa. Element Hard Real-Time Firm Real-Time Soft Real-Time Ważny – brak sensu po Deadline (𝒕𝑻 ) Krytyczny – brak tolerancji Ważny – tolerancja opóźnień deadline Zysk po deadline (𝒕𝑻 ) Zawsze Z(t)=0 Zawsze Z(t)=0 Z(t) może spadać do 0 Stopniowa degradacja Reakcja na opóźnienie Katastrofalna Utrata użyteczności zadania działania Przykłady Krytyczne systemy Transakcje giełdowe, Gry, aplikacje interaktywne zastosowania sterowania multimedia RTOS – Real Time Operating System Podstawowe wymaganie – określenie najgorszego (najdłuższego) czasu, po jakim urządzenie komputerowe wypracuje odpowiedź po wystąpieniu zdarzenia. Twarde (hard) - takie, dla których znany jest najgorszy (najdłuższy) czas odpowiedzi, oraz wiadomo jest, że nie zostanie on przekroczony. Miękkie (soft) - takie, które starają się odpowiedzieć najszybciej jak to możliwe, ale nie wiadomo jest, jaki może być najgorszy czas odpowiedzi. Podstawowym celem w tego typu systemach operacyjnych jest algorytm szeregowania oraz podziału czasu czyli decyzja któremu procesowi przydzielić procesor i na jak długo. Wbudowane RTOS Większość to systemy hard real-time Zakończenie zadania najczęściej w czasie mikrosekund lub milisekund Małe zapotrzebowanie na peryferia i zasoby Projektowane do określonych zadań Bardzo często krytycznych jeśli chodzi o zdrowie i życie ludzkie Desktop lub serwer RTOS Większość to systemy soft real-time Zakończenie zadania najczęściej w czasie od milisekund..sekund Windows CE, niektóre dystrybucje Linux, QNX, VxWorks… Planista (task scheduler) w SO Zadanie (ang. Task) – zdarzenie z których składa się każdy program. Zdarzenia mogą pochodzić od zegara, zadań, sygnałów wejściowych lub wyjściowych. Planista działa na podstawie algorytmu szeregowania (scheduling algorithm) i odpowiada za: Podział czasu procesora (time-sharing) - Procesor jest zasobem ograniczonym, więc planista zarządza nim tak, aby różne zadania mogły z niego korzystać w odpowiednich momentach. Priorytetyzację - Zadania krytyczne (o wyższym priorytecie) mogą przerwać mniej ważne zadania. Zapewnienie terminowości - Szczególnie ważne w systemach czasu rzeczywistego, gdzie kluczowe zadania muszą być ukończone w określonym czasie. 1. System blokowalnych zadań W systemach nieblokowalnych każde zadanie o wysokim priorytecie (Hi) może przerwać wykonanie zadania o niskim priorytecie (Lo) natychmiast po pojawieniu się (w momencie czarnej kropki). Zadanie o niskim priorytecie (Task B) rozpoczyna się i jest wykonywane do momentu, gdy pojawia się zadanie o wyższym priorytecie (Task A). Task A natychmiast przerywa Task B i jest wykonywane do końca. Po zakończeniu Task A, Task B jest kontynuowane. Zalety: o Zadania o wysokim priorytecie są realizowane najszybciej, co jest kluczowe w systemach czasu rzeczywistego. o Zapewnia wysoką responsywność dla zadań krytycznych. Wady: o Zadania o niskim priorytecie mogą zostać wielokrotnie przerywane, co prowadzi do ich głodzenia (starvation) – mogą nigdy się nie zakończyć. 2. System nieblokowalnych zadań W systemach blokowalnych zadanie o wyższym priorytecie (Task A) musi poczekać, aż obecnie wykonywane zadanie o niższym priorytecie (Task B) zakończy aktualnie wykonywany fragment (np. sekcję krytyczną). Zadanie o niskim priorytecie (Task B) rozpoczyna się i jest wykonywane. Gdy pojawia się zadanie o wyższym priorytecie (Task A), nie przerywa ono natychmiast Task B. Musi poczekać, aż Task B zakończy swoją sekcję. Dopiero po zakończeniu Task B, Task A rozpoczyna swoje wykonanie. Zalety: o Chroni zadania o niższym priorytecie przed zbyt częstym przerywaniem. o Unika zjawiska priorytetowej inwersji, w której zadanie o niskim priorytecie mogłoby nie zakończyć się z powodu ciągłego przerywania. Wady: o Zadania o wysokim priorytecie mogą być opóźnione, co w krytycznych systemach czasu rzeczywistego może być niedopuszczalne. o Planista Real-time Periodyczne zadania pojawiają się w stałych odstępach czasu, są realizowane w sposób przewidywalny, często mają najwyższy priorytet. Sporadyczne zadania pojawiają się w różnych odstępach czasu ale jest czas minimalny, wymagają uwzględnienia minimalnych czasów między wystąpieniami. Aperiodyczne zadania pojawiają się w różnych odstępach czasu bez czasu minimalnego, muszą być obsługiwane w sposób elastyczny, w zależności od dostępności zasobów - brak (patrz pierwsze podejście – mrugające LEDy) - Priority-driven (rozwiązanie do podejścia trzeciego) - Fixed- Priority Schedulers (FPS) – plan z ustalonymi priorytetami - Dynamic-Priority Schedulers (DPS) – plan z dynamicznie ustalonymi priorytetami - Time-driven (podejście czwarte) - Share-driven (rozwiązanie do podejścia drugiego) 1. Planista Time-driven Cechy: o Harmonogram zadań jest określany na podstawie upływu czasu. o Wszystkie zadania mają wcześniej ustalony, sztywny plan działania. o Planista działa w oparciu o precyzyjnie zaplanowane interwały czasowe. o Nie uwzględnia dynamicznej zmienności obciążenia systemu. Przykład: Mrugające diody LED z ustaloną częstotliwością – każde zadanie jest wywoływane w określonych odstępach czasu (np. co 50 ms). Zastosowanie: o Systemy o stałych i przewidywalnych wymaganiach czasowych. o Typowe w systemach sterowania przemysłowego. Zalety: o Przewidywalność – system jest deterministyczny. o Idealny do aplikacji krytycznych o wysokiej niezawodności. Wady: o Brak elastyczności – nie radzi sobie dobrze z niespodziewanymi zdarzeniami. o Trudność w optymalizacji przy zmiennym obciążeniu. 2. Planista Priority-driven Cechy: o Zadania są harmonogramowane na podstawie priorytetów. o Zadania o wyższym priorytecie są wykonywane przed zadaniami o niższym priorytecie. o Może działać w dwóch trybach: ▪ Fixed-Priority Scheduler (FPS): Priorytety zadań są ustalone na stałe. ▪ Dynamic-Priority Scheduler (DPS): Priorytety zadań są dynamicznie zmieniane w zależności od sytuacji. Przykład: o Sterowanie maszyną w fabryce, gdzie zadania krytyczne (np. zatrzymanie w sytuacji awaryjnej) mają najwyższy priorytet. Zastosowanie: o Systemy, gdzie ważność zadań jest różna i priorytety odzwierciedlają ich znaczenie. o Stosowany zarówno w systemach czasu rzeczywistego miękkiego (soft real-time), jak i twardego (hard real- time). Zalety: o Elastyczność – system może reagować na dynamiczne zmiany. o Możliwość nadania priorytetów zadaniom krytycznym. Wady: o Może wystąpić starvation – zadania o niskim priorytecie mogą nigdy nie zostać wykonane. o Trudność w przewidywaniu dokładnego czasu wykonania w dynamicznych środowiskach. 3. Planista Share-driven Cechy: o Zadania dzielą dostępne zasoby systemowe w sposób proporcjonalny do ich wymagań. o System nie opiera się na sztywnych priorytetach czy sztywnych interwałach czasowych. o Stosowane algorytmy optymalizują podział zasobów, tak aby wszystkie zadania mogły korzystać z nich w sposób sprawiedliwy lub odpowiednio do wymagań. Przykład: o Przydzielanie pasma w sieci komputerowej, gdzie każde zadanie (np. przesyłanie danych) otrzymuje odpowiedni „udział” pasma. Zastosowanie: o Systemy, gdzie zasoby są współdzielone między wieloma zadaniami. o Systemy multimedialne, aplikacje działające na serwerach. Zalety: o Sprawiedliwy podział zasobów. o Efektywność w systemach wielozadaniowych. Wady: o Mniejsza deterministyczność w systemach czasu rzeczywistego twardego. o Trudność w implementacji w systemach krytycznych. Cechy Time-driven Priority-driven Share-driven Podstawa Stały czas (interwały) Priorytety zadań Podział zasobów harmonogramu Średnia (stałe priorytety) / Wysoka Elastyczność Niska Wysoka (dynamiczne priorytety) Deterministyczność Bardzo wysoka Średnia Niska Systemy sterowania Sieci komputerowe, systemy Zastosowania Systemy krytyczne, multimedialne przemysłowego współdzielone freeRTOS Popularny system operacyjny czasu rzeczywistego dla różnych urządzeń. Ponieważ kernel jest bardzo mały (zawiera 3 pliki w C) to w wersji binarnej zajmuje typowo od 6 kB do 9 kB pamięci ROM. Parametry: ❖ Stosowany na wielu różnych architekturach sterowników (ponad 40), ❖ Szybki w działaniu (bardzo mały kernel), ❖ Do energooszczędnych zastosowań, ❖ Łatwy do poznania i nauki, ❖ Planista może być konfigurowany zarówno z blokowanymi jak i nieblokowanymi zadaniami, ❖ Stale rozwijany pod licencją MIT. Używać czy nie używać SO na μC? Generalnie tak jeśli mamy „mocny” sprzęt i wykonujemy wiele zadań w tym samym czasie; Gdy używamy prostych mikrokontrolerów to zależy od aplikacji ale… Nawet na prostych μC możemy używać SO, np. w celu zwiększenia możliwości portowania; Używanie wielu zadań jest znacznie prostsze jeśli używamy SO. W4 Windows Cechy systemu operacyjnego a) Wielozadaniowość – równoczesne wykonywanie więcej niż jednego procesu. System przełącza procesor między różnymi zadaniami tak szybko, że użytkownik odnosi wrażenie, że są one wykonywane jednocześnie. Mechanizm ten opiera się na harmonogramowaniu (scheduler) i podziale czasu (time-sharing). b) Wywłaszczalność (planista, dyspozytor) – możliwość wstrzymywania aktualnie wykonywanego zadania aby umożliwić działanie innego zadania Wywłaszczenie to zdolność systemu operacyjnego do wstrzymania wykonywania jednego zadania, aby umożliwić działanie innego, bardziej krytycznego zadania. Planista (scheduler): Decyduje, które zadanie ma być wykonywane w danym momencie. Dyspozytor (dispatcher): Odpowiada za przełączanie procesora między zadaniami. c) Wielowątkowość – możliwość wykonywania wielu zadań (wątków) w ramach jednego procesu. Wątek to lekka jednostka wykonawcza, która dzieli przestrzeń adresową z innymi wątkami w tym samym procesie. d) Wielobieżność – możliwość bezpiecznego przerwania wykonywania procesu (przez wykonanie tego samego procesu od początku) a następnie powrócenie do jego kontynuacji. Proces może zostać wstrzymany (np. zapisując jego stan), aby inne zadania mogły być wykonywane, a następnie wznowiony, gdy procesor ponownie stanie się dostępny. e) Skalowalność – możliwość powiększania systemu Podział systemów operacyjnych ze względu na budowę i. Systemy z jądrem monolitycznym ii. Systemy z jądrem hybrydowym iii. Systemy z mikrojądrem (nano…) Jądro = ang. kernel System operacyjny - oprogramowanie zarządzające systemem komputerowym, tworzące środowisko do uruchamiania i kontroli zadań. Jądro systemu operacyjnego - podstawowa część systemu operacyjnego, która jest odpowiedzialna za wszystkie jego zadania Jądro hybrydowe to model jądra systemu operacyjnego, który łączy cechy jądra monolitycznego i mikrojądra. Zachowuje wysoką wydajność jądra monolitycznego, ale dodaje większą modularność i elastyczność charakterystyczną dla mikrojąder. Kluczowe cechy: Wydajność: Podstawowe funkcje (np. zarządzanie pamięcią, procesami, system plików) działają w trybie jądra, podobnie jak w jądrze monolitycznym. Modularność: Dodatkowe usługi (np. podsystemy użytkownika, interfejsy API) są realizowane jako osobne moduły, często działające w trybie użytkownika. Architektura jądra hybrydowego (na przykładzie Windows NT) Warstwa aplikacji użytkownika (User Mode): Aplikacje i podsystemy: Działa tutaj większość aplikacji użytkownika, np. aplikacje Win32, POSIX, OS/2. Podsystemy te odpowiadają za tłumaczenie żądań użytkownika na operacje rozumiane przez jądro. Logon: Obsługa uwierzytelniania i logowania użytkowników. Warstwa jądra (Kernel Mode): Składa się z trzech głównych komponentów: Executive: Wykonuje zaawansowane funkcje systemowe, takie jak: 1. Zarządzanie pamięcią (VM – Virtual Memory). 2. Zarządzanie procesami (Process Manager). 3. Obsługa wejścia/wyjścia (I/O Manager). Mikrojądro (Microkernel) - Minimalna część jądra odpowiadająca za podstawowe funkcje, takie jak przełączanie kontekstu, obsługa przerwań, komunikacja między procesami. HAL (Hardware Abstraction Layer) - Warstwa abstrakcji sprzętowej, która umożliwia jądru współpracę z różnymi typami sprzętu. Sprzęt (Hardware) - Fizyczny komponent komputera, z którym komunikuje się jądro przez HAL. Zalety jądra hybrydowego 1. Wysoka wydajność - Funkcje krytyczne dla wydajności (np. zarządzanie pamięcią, obsługa procesów) działają w trybie jądra. 2. Modularność - Możliwość dodawania/usuwania komponentów bez konieczności zmiany całego jądra. 3. Bezpieczeństwo - Większość podsystemów działa w trybie użytkownika, co ogranicza ryzyko awarii całego systemu w przypadku ich błędów. 4. Przenośność - Dzięki HAL, system operacyjny może działać na różnych platformach sprzętowych. Wady jądra hybrydowego 1. Kompleksowość - Połączenie dwóch modeli jądra (monolitycznego i mikrojądra) zwiększa złożoność kodu i utrudnia jego rozwój. 2. Potencjalne spadki wydajności - Komunikacja między modułami w różnych trybach (np. jądro–użytkownik) może generować dodatkowe opóźnienia. Jądro monolityczne to model systemu operacyjnego, w którym wszystkie podstawowe funkcje systemowe (np. zarządzanie procesami, pamięcią, urządzeniami I/O) są wykonywane w trybie jądra. Kod jądra działa jako jeden spójny blok (monolit) w przestrzeni jądra, co oznacza, że wszystkie jego części mają pełny dostęp do sprzętu i zasobów systemowych. Funkcje takie jak sterowniki urządzeń, system plików, czy stos sieciowy działają w trybie jądra, co zapewnia szybki dostęp do zasobów. Architektura jądra monolitycznego Aplikacje użytkownika - Działają w trybie użytkownika i komunikują się z jądrem za pośrednictwem wywołań systemowych (system calls). Jądro systemu operacyjnego: o Obsługuje procesy, pamięć, zarządzanie urządzeniami i system plików. o Wspiera sterowniki urządzeń bezpośrednio w przestrzeni jądra. Sprzęt (procesor, pamięć, urządzenia): o Jądro ma bezpośredni dostęp do wszystkich zasobów sprzętowych. Aplikacje użytkownika przesyłają żądania do jądra, które zarządza sprzętem i zasobami systemowymi. Jądro działa jako centralny komponent kontrolujący cały system. Zalety jądra monolitycznego 1. Wysoka wydajność: Wszystkie operacje są realizowane w trybie jądra, co eliminuje konieczność przełączania kontekstu między różnymi warstwami (jak w mikrojądrze). Szybki dostęp do zasobów sprzętowych. 2. Bezpieczeństwo użytkownika: Operacje użytkownika są oddzielone od jądra, dzięki czemu użytkownik nie może bezpośrednio zmodyfikować systemu operacyjnego ani uszkodzić sprzętu. 3. Prostota: Kod jądra jest jednorodny, co ułatwia implementację podstawowych funkcji systemowych. 4. Szeroka kompatybilność: Większość sterowników działa w przestrzeni jądra, co pozwala na łatwą obsługę urządzeń. Wady jądra monolitycznego 1. Brak izolacji między komponentami jądra: Wszelkie błędy w kodzie jądra (np. w sterownikach) mogą spowodować awarię całego systemu. Awaria jednego komponentu (np. sterownika) może unieruchomić cały system. 2. Trudności w modyfikacji: Każda zmiana w jądrze wymaga rekompilacji całego kodu jądra. Rozszerzalność systemu jest ograniczona. 3. Zagrożenie stabilności: Sterowniki urządzeń działające w trybie jądra mogą być źródłem problemów, jeśli są źle zaimplementowane. Mikrojądro to minimalistyczna architektura jądra systemu operacyjnego, która wykonuje jedynie najbardziej podstawowe funkcje systemowe w trybie jądra. Reszta funkcji (np. obsługa urządzeń, system plików, stos sieciowy) jest realizowana w trybie użytkownika przez tzw. serwery. Podstawowe funkcje mikrojądra: Zarządzanie procesami (przełączanie kontekstu). Komunikacja między procesami (IPC – Inter-Process Communication). Obsługa przerwań sprzętowych. Architektura mikrojądra Warstwy: 1. Mikrojądro: o Działa w trybie jądra. o Realizuje tylko kluczowe funkcje, takie jak przełączanie kontekstu, komunikacja IPC oraz zarządzanie przerwaniami. 2. Serwery: o Działają w trybie użytkownika. o Obsługują funkcje takie jak zarządzanie plikami, obsługa urządzeń, czy stos sieciowy. o Każdy serwer jest oddzielnym procesem, co zwiększa stabilność systemu (błąd jednego serwera nie powoduje awarii całego systemu). 3. Aplikacje - Komunikują się z serwerami i mikrojądrem za pomocą komunikacji międzyprocesowej (IPC). Komunikacja - IPC (Inter-Process Communication): Kluczowy mechanizm w mikrojądrze. Umożliwia wymianę danych między serwerami, aplikacjami i mikrojądrem. Zalety: 1. Stabilność - Komponenty systemu są izolowane w różnych procesach – awaria jednego nie wpływa na inne. Jeśli sterownik urządzenia (serwer) ulegnie awarii, może zostać ponownie uruchomiony bez wpływu na jądro. 2. Modularność - Łatwość modyfikacji i rozbudowy systemu poprzez dodawanie lub modyfikowanie serwerów. Sterowniki i funkcje systemowe można aktualizować bez restartowania systemu. 3. Bezpieczeństwo Ograniczenie dostępu do krytycznych funkcji systemowych (większość działań odbywa się w trybie użytkownika). Zmniejsza ryzyko eskalacji błędów lub ataków. 4. Przenośność: Prosta konstrukcja mikrojądra ułatwia jego implementację na różnych platformach sprzętowych. Wady: 1. Wydajność - Mikrojądro wymaga intensywnej komunikacji między serwerami i mikrojądrem (IPC), co może obniżać wydajność. Opóźnienia wynikające z przełączania kontekstu między procesami. 2. Kompleksowość - Programowanie serwerów wymaga większego wysiłku, ponieważ funkcje są rozproszone. Mikrojądra są często stosowane w systemach, gdzie stabilność, bezpieczeństwo i modularność są priorytetowe. Przykłady zastosowań: 1. Systemy czasu rzeczywistego (RTOS): o freeRTOS, QNX: W systemach przemysłowych, sterownikach urządzeń i samochodach. o Umożliwiają obsługę krytycznych zdarzeń w czasie rzeczywistym. 2. Systemy edukacyjne: o Minix: Często używany do nauki budowy systemów operacyjnych. 3. Systemy wbudowane: o Obsługa urządzeń IoT, smartfonów, urządzeń medycznych, systemów sterowania. 4. Bezpieczne systemy operacyjne: o Mikrojądra są popularne w systemach, gdzie bezpieczeństwo jest kluczowe (np. systemy lotnicze, bankowe). Cechy Mikrojądro Jądro monolityczne Jądro hybrydowe Rozmiar jądra Małe Duże Średnie Modularność Wysoka Niska Średnia Stabilność Bardzo wysoka Niska (awaria sterownika wpływa na cały system) Wysoka Wydajność Niższa (komunikacja IPC) Bardzo wysoka Zbliżona do monolitycznego Przykłady QNX, Minix, freeRTOS Linux, UNIX Windows NT, Mac OS Dlaczego Windows XP? ❖ Sukcesor rodziny systemów NT (łącznie z Windows 2000) – pojawił się w 2001r. ❖ Połączenie systemów Microsoftu, linii „domowych” (9x) i „biurowych” (NT) ❖ XP to skrót od „eXPerience” (enhanced user experience) ❖ Wsparcie dla tego systemu już zakończone (XP) ❖ Podstawa dla systemu wbudowanego (embedded) – bankomaty, terminale itp. Popularność OS (2023 r.) Rodzina NT: krótka historia ✓ Początek projektu – 1988 r. (NT3.1 – 1993 r., NT4.0 – 1996 r.) ✓ Microsoft twierdził że NT to „New Technology” w przeciwieństwie do swoich poprzedników zarówno Windows jak i UNIX (przez „wrogów” tłumaczone jako „Not Today, Not Tomorrow, but Nice Try”) ✓ „… Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly)” (by Matt Welsh) ✓ Bardzo skomplikowane tworzenie sterowników do NT → mała popularność w porównaniu do 9x Wewnątrz NT i XP OS Win32 jest główną częścią systemu z punktu widzenia programistów; POSIX.1 subsystem również występuje (chociaż dzisiaj Microsoft oferuje SFU - Windows Services for UNIX) OS/2 API miało być naturalnym ale ostatecznie Win32 wygrało (głównie ze względu na popularność Windows 3.x). OS/2 zostało usunięte z XP. Interix (POSIX support) POSIX: Portable Operating System Interface for Unix – standard API, system commands, shell. [$$!] Kompletna instalacja Interix zawierała (w wersji 3.5): Ponad 350 Unix utilities takich jak vi, ksh, csh, ls, cat, awk, grep, kill, itp. Kompletny manual do utilities i API Kompilator GCC 3.3 includes i libraries cc/c89-like wrapper do Microsoft Visual Studio command-line C/C++ compiler GNU Debugger X11 client applications i libraries (bez X serwera, można użyć na przykład Xming) Posiada możliwości Unix root (czyli setuid files) Zawiera pthreads, shared libraries, DSOs, job control, signals, sockets, shared memory XP OS sub-layers Subsystemy (czyli POSIX, Win32) istnieją ponad kernel-mode jako user-mode subsystemy→ z możliwością rozszerzenia (ale XP wspiera tylko Win32) Kod zależny od procesora (hardware) umieszczony w HAL DLL (hardware abstraction layer) – potencjalne ułatwienie portowania OS na inne architektury, zmniejszenie ryzyka pojawiania się błędów podczas portowania. XP: niektóre właściwości Wsparcie językowych wersji - Użycie NLS API (national language support) bardzo upraszcza użycie różnych języków nawet wewnątrz jednego systemu i wpiera tworzenie wielojęzykowych aplikacji, UNICODE jest naturalnie wspierany Multiprocessing - XP był projektowany specjalnie do SMP (symmetrical multiprocessing). Tak naprawdę GUI współpracuje tylko gdy zastosowana jest technologia HT… Single-core hardware nie „współpracuje” z Windows XP! Kompatybilność - Win32 subsystem wprowadza kompatybilność wstecz z systemami Win9x w większości wypadków z ochroną procesów Niezawodność - W porównaniu z Win9x lepsza ochrona zasobów zarówno od strony hardware jak i software. XP: jądro (mikrojądro) o Jądro ::= Executive (kernel-mode) + subsystems (user-mode) o Zorientowane obiektowo: każdy obiekt (event, mutex, semaphore, thread, timer, interrupt, process, profile) posiada własne przywileje o Mikrojądro nie podlega wpływom stronicowania (swapping) XP: pamięć wirtualna o Każdy proces posiada wirtualny adres przestrzeni adresowej o Przykład: skompilowanie i uruchomienie co najmniej dwóch instancji kodu. Obie instancje mają ten sam kod. W obu instancjach „zmienna” ma ten sam adres o Wartość „zmiennej” w obu przypadkach jest różna, fizycznie zmienne są przechowywane w różnych miejscach w pamięci. Chociaż wirtualny adres (uzyskany za pomocą operatora &) jest taki sam w obu przypadkach. NTFS - system plików o Wyparł FAT i HPFS (używany w OS/2) o ACL (Access List Control) – mechanizm bezpieczeństwa o Księgowanie (Journal) operacji dyskowych o Pliki są reprezentowane jako metadata a nie czyste ciągi danych o Wspieranie linków i montowań o Wolumin: podobnie jak dysk logiczny ale może łączyć wiele urządzeń, RAIDy, … NTFS i ACL Każdy plik lub katalog dziedziczy atrybuty bezpieczeństwa od „rodzica” albo ma własne. Uwaga: ta możliwość nie jest dostępna w wersji Home Edition. NTFS: dodatkowe zabezpieczenia Jest bardzo trudne (prawie niemożliwe) odszyfrowanie danych bez prawidłowego klucza użytkownika, dlatego trzeba być bardzo ostrożnym przy włączeniu tej opcji! Rekomendowane jest użycie SmartCard (niezbędna Vista lub wyżej) do przechowywania certyfikatów do EFS. Pliki i katalogi w NTFS mogą być kompresowane i szyfrowane AES (Uwaga: ta możliwość nie jest dostępna w wersji Home Edition). EFS (Encrypting File System) jest niewidoczny dla użytkownika (nie wymaga dodatkowych operacji od użytkownika). Używana jest Symmetric cryptography do ochrony danych, używane są public-key cryptography i symmetric key cryptography. NTFS kontra FAT o FAT jest bardzo prosty i do tego popularny (aparaty fotograficzne, karty pamięci, …). Jest kompatybilny z większością systemów operacyjnych. Wymaga bardzo mało zasobów (CPU, RAM). o NTFS obsługuje duże pliki danych (>2/4 GiB), szyfrowanie, dynamiczne wolumeny, hard- i soft dowiązania i prawa dostępu użytkownika (ACL). o NTFS obsługuje księgowanie i jest odporny na zakłócenia zasilania. o NTFS ma wbudowany mechanizm przeciw fragmentacji plików Win32 subsystem i WinAPI o Win32 jest głównym subsystemem w architekturze WindowsNT, inne subsystemy często wywołują funkcje Win32 o Win32 API jest kompatybilny wstecz z wcześniejszymi wersjami Windows (w większości wypadków) o WinAPI jest również obsługiwany w urządzeniach mobilnych / wbudowanych o Obiekty systemu są dostępne jako uchwyty o Olbrzymie zasoby MSDN: API dokumentacja, przykłady, … o Setki funkcji i specjalnych struktur danych (bagaż kompatybilności wstecz) o Prawie wszystko jest możliwe z funkcjami API… oczywiście jeśli jest wystarczająco dużo czasu o WinAPI może być bardzo atrakcyjne dla aplikacji RDP. Nie jest potrzebne.NET frameworks ani nawet biblioteki C/C++. Aplikacje mogą być uruchamiane na świeżej instalacji Windows. Programowanie w języku C o Aplikacja może otwierać tyle okien ile potrzebuje o Użytkownik może tworzyć swoje własne klasy okien o Message-driven – typ komunikacji między OS i oknami → tego typu komunikacja może być zaadoptowana do systemów wbudowanych lub urządzeń z kodem OS-like o Jedna funkcja callback przetwarzania wiadomości okien o Większość prototypów funkcji API umiejscowiona w pliku nagłówkowym windows.h Struktura aplikacji Windows o Typowa aplikacja zawiera rejestrację klas, tworzenie okna, pętlę wiadomości i funkcję przetwarzania wiadomości. o Kod zaczyna się od funkcji WinMain() a nie standardowej main(). o Uchwyt instancji (HINSTANCE type) reprezentuje uruchomiony proces w systemie a pojedynczy plik EXE może być uruchomiony wielokrotnie tworząc wiele procesów działających równolegle w pamięci. Rejestracja klas w WinAPI o Każda klasa jest reprezentowana przez identyfikator tekstowy (np. "MyClass") o Wiele klas już jest zarejestrowanych np. "BUTTON", "EDIT", … o Window-class jest receptą na łatwe tworzenie podobnych okien w przyszłości. Acz typowo aplikacja tworzy jedno okno główne. Przetwarzanie wiadomości (message processing) o Wiadomość jest unikalną liczbą całkowitą z dwoma opcjonalnymi parametrami; o Setki wiadomości są już predefinowane; użytkownik jednak może zdefiniować własne; o Wiadomość jest przetwarzana w zdefiniowanej przez użytkownika funkcji ; o Minimalny kod przetwarzania wiadomości zawiera wywołanie PostQuitMessage() do WM_DESTROY i DefWindowProc() do pozostałych wiadomości. Pętla wiadomości o Wiadomość (message) – to oznaczenie dla tłumacza wiadomości (kombinacja znaków która pomaga użytkownikowi używać w aplikacji nie tylko myszki i menu ale również klawiatury). o Pętla kończy się po wykonaniu PostQuitMessage(). o PeekMessage() może być użyte do określenia czy wiadomość oczekuje w kolejce czy nie. Rzadziej używane jest GetMessage(). Przykłady aplikacji w OpenGL. Tworzenie okna o Każde okno jest reprezentowane przez uchwyt (HWND); o Każde okno należy do określonej klasy, posiada ustawione atrybuty i pozycję na ekranie; o Ustawienie WS_VISIBLE (albo wywołanie później ShowWindow()) powoduje że okno staje się widoczne; o Prawie wszystkie kontrolki w Windows (włączając w to przyciski, menu, desktop) to okna. o Jeśli okno należy do innego okna to jest oknem-dzieckiem (WS_CHILD). Działający przykład Aplikacja Message-driven o Łatwy mechanizm obsługi zewnętrznych zdarzeń; o Brak mechanizmu wyboru → cykle CPU nie są marnowane; o Ważne założenie: przetwarzanie wiadomości trwa tylko krótki czas po czym kontrola wraca do systemu; o Dokładnie tylko jedna wiadomość jest przetwarzana w danym momencie – brak kłopotów związanych z wielozadaniowością (domyślnie aplikacja jest jedno- wątkowa); o Trudne do wykonania zadanie tracenia czasu w tle przy użyciu typowej aplikacji; o Prawie niemożliwe wywołanie funkcji blokującej (np. I/O) wewnątrz zdarzenia. o case WM_CREATE: for(;;); break; → 'Houston, we have a problem' Jak wywołać funkcję blocking wewnątrz wiadomości? o Próba – użyć wersji non-blocking tej funkcji jeśli to możliwe ☺ o Jeśli naprawdę istnieje potrzeba wywołania takiego kawałka kodu: for(;;); należy rozważyć użycie wątku. o Wątek jest bardzo podobny do procesu, ale zamiast być uruchomionym w swojej wydzielonej pamięci, dzieli ten sam obszar pamięci z procesem głównym. o W języku C wątek jest funkcją uruchamianą niezależnie od innych funkcji (i prawdopodobnie w tym samym czasie). o Taka funkcja ma dostęp do pamięci programu w tym do zmiennych globalnych. o Należy pamiętać o volatile w takim przypadku! Czy potrzebne są nam wątki? o Większość aplikacji nie potrzebuje wielu wątków; o Użycie wątków komplikuje program (ciężko albo i niemożliwe jest odgadnięcie kolejności wykonywania); o Funkcja Reentrant, krytyczna część, synchronizacja kodu jest niezbędna→ znacznie utrudnione tworzenie aplikacji; o Jedno-wątkowy proces może użyć jednego rdzenia CPU, dobrze zaprojektowany wielo-wątkowy proces może mieć przewagę wykorzystania wszystkich rdzeni / CPU w tym samym czasie. o Wbudowane funkcje wątków WinAPI mogą być używane ale lepiej używać biblioteki pthreads (biblioteki POSIX) dostępnej dla Windows i Linux, aby łatwiej przenosić kod między systemami. Użycie wątków Win32 W procesorze 4-rdzeniowym nasz proces może zająć maksymalnie 25% mocy procesora: Co nie znaczy że system zawsze alokuje ten sam rdzeń do danego wątku. Jądro (task scheduler) daje dostęp procesowi (wątek) do procesora w bardzo krótkich odcinkach czasu. Przełączanie zadań odbywa się z taką częstotliwością że użytkownik ma wrażenie że wiele zadań (aplikacji) działa równolegle. W rzeczywistości aplikacje sterowane wiadomościami większość czasu czekają na zdarzenie i nie używają CPU. Ale jeden rdzeń do jednego wątku to problem techniczny! Wątki i volatile W tym przypadku wewnętrzne podstawienia są zoptymalizowane i a=1 i a=2 są ignorowane przez kompilator i tylko a=3 jest przez nas obserwowane. b jest volatile dlatego nie jest optymalizowane więc możemy zobaczyć wszystkie jego wartości (1, 2, 3). WinAPI w C#/.NET i DLLs o Platforma.NET jest ponad WinAPI. Jest to zorientowany obiektowo zestaw funkcji zastępujący funkcje WinAPI. o Wiele funkcji WinAPI nie jest dostępnych domyślnie ale mogą być dynamicznie importowane w czasie działania aplikacji. o Ten mechanizm używa Dynamic Link Libraries (DLLs) o DLL są wspierane przez OS (podobny mechanizm istnieje w Linux). Proces wywołuje funkcje LoadLibrary i GetProcAddress. Kod jest ładowany do wywołującego procesu pod odpowiedni adres i staje się częścią programu aż do rozładowania biblioteki (FreeLibrary). o Składnia C# jest prosta -.NET wykonuje wszystkie „techniczne czynności” automatycznie [DllImport("user32.dll", CharSet = CharSet.Unicode)] public static extern int MessageBox(IntPtr hWnd, String text, String caption, uint type); I teraz funkcja MessageBox może być użyta w C#. Dlaczego używać DLL? o Część kodu może być wymieniana w czasie działania programu głównego o Różne języki mogą być mieszane dopóki DLL jest skompilowanym kodem (C, C++, C#, Java, Matlab, …) o „Zewnętrzne” funkcje mogą być stosowane bez dostępu do kodu źródłowego (np. komercyjne biblioteki do obliczeń numerycznych) o Łatwe do upgrad’u (patches), bez zmiany kodu głównego – wystarczy podmienić DLL. W5 UNIX, Linux UNIX Napisany w 1969 (assembler) w AT&T Przepisany w C w 1973 (D. M. Ritchie) → łatwiejsze przeportowanie na inne platformy sprzętowe Podejście akademickie: BSD (Berkeley Software Distribution) Berkeley sockets (lub BSD sockets) API do komunikacji internetowej→ de facto światowy standard do dzisiaj Dzisiaj - główne wersje open-source: FreeBSD, NetBSD, OpenBSD, Produkty komercyjne: HP/UX, AIX, macOS GNU GNU General Public License – licencja wolnego i otwartego oprogramowania stworzona w 1989 roku przez Richarda Stallmana i Ebena Moglena na potrzeby Projektu GNU, zatwierdzona przez Open Source Initiative. Celem licencji GNU GPL jest przekazanie użytkownikom czterech podstawowych wolności: ✓ wolność uruchamiania programu w dowolnym celu (wolność 0) ✓ wolność analizowania, jak program działa i dostosowywania go do swoich potrzeb (wolność 1) ✓ wolność rozpowszechniania niezmodyfikowanej kopii programu (wolność 2) ✓ wolność udoskonalania programu i publicznego rozpowszechniania własnych ulepszeń, dzięki czemu może z nich skorzystać cała społeczność (wolność 3). MINIX Unix-like system napisany przez A. Tanenbaum (początkowo do edukacji) Bardzo małe potrzeby sprzętowe, łącznie z systemami wbudowanymi Mikrojądro (microkernel) (ok. 6000 linii kodu), duża niezawodność 1992, comp.os.minix – Tanenbaum-Torvalds debatowali nad architekturą jądra. A.T. argumentował że ‘monolithic Linux kernel is obsolete’ (w wersji 2.6.x jądra są miliony linii kodu) Linux – hierarchia W Linuksie wszystko jest plikiem, a jeśli nie jest plikiem to jest procesem. Najważniejsze katalogi w katalogu głównym /etc – pliki konfiguracyjne /dev – pliki reprezentujące urządzenia (device) /proc – pliki reprezentujące strukturę jądra (pliki tekstowe) /var – pliki systemowe i aplikacji z danymi i logi /usr – pliki użytkowników /sbin – aplikacje systemowe /bin – komendy systemowe (exe) Prawa dostępu ▪ W Linuksie każdy plik ma właściciela i grupę reprezentowane przed numer (IDS) ▪ Każdy plik jest reprezentowany przez zbiór bitów oznaczających możliwość czytania, zapisywania i wykonywania pliku ▪ Prawa są reprezentowane jako 3 liczby ósemkowe. Określają, jakie operacje mogą być wykonane na pliku lub katalogu: r (read) odczyt, w (write) zapis, x (execute) wykonanie (dla plików – uruchomienie, dla katalogów – przejście). Prawa są przypisane do trzech grup: Właściciel (user): pierwsze trzy znaki. Grupa (group): kolejne trzy znaki. Pozostali (others): ostatnie trzy znaki. Prawa są kodowane binarnie i reprezentowane liczbowo: r: 4 (binarnie 100). w: 2 (binarnie 010). x: 1 (binarnie 001). Przykład: rw- = 4 + 2 = 6. r-- = 4. rwx = 4 + 2 + 1 = 7. chmod – zmienia prawa dostępu do pliku Modyfikowanie praw dostępu za pomocą symboli: chmod +rwx file: dodaj prawa. chmod -rwx file: usuń prawa. chmod u=rwx,g=rx,o=r file: ustaw określone prawa. Modyfikowanie praw w formacie ósemkowym: chmod 755 file: ustaw prawa rwxr-xr-x. chown – zmienia właściciela i grupę pliku Sposób użycia: chown user file: zmienia właściciela. chown user:group file: zmienia właściciela i grupę. Przykład: chown stud file.txt: zmienia właściciela pliku file.txt na użytkownika stud. Zwykły użytkownik nie może zmienić właściciela pliku, który nie należy do niego. chmod a+rx app.bin – pozwala wszystkim (all) odczytać oraz uruchomić zbiór app.bin chmod o-rwx file.txt – zabrania pozostałym (others) czytania, pisania i uruchamiania pliku file.txt chmod u+rw,go-rwx app.bin – pozwala właścicielowi pliku na odczytywanie i pisywanie do pliku oraz zabrania grupie oraz pozostałym na czytanie, pisanie i uruchamianie pliku app.bin Linux – montowanie FS ✓ Montowanie innych FileSystemów jest bardzo proste. Montowanie to proces łączenia systemu plików (FS) z określonym punktem montowania (mount point) w hierarchii katalogów Linuxa. Po zamontowaniu system plików staje się dostępny dla użytkowników i aplikacji w określonej lokalizacji. ✓ Przejrzyste dla użytkownika ✓ Łatwe do zmiany konfiguracji bez zmiany struktury FileSystemu. Punkty montowania można łatwo zmieniać, nie wpływając na strukturę całego systemu plików. Montowanie i odmontowywanie systemów plików jest dynamiczne – można to zrobić bez restartowania systemu ✓ Montowanie można wykonywać ręcznie za pomocą polecenia mount. Można również skonfigurować automatyczne montowanie w pliku /etc/fstab. Linux obsługuje różne systemy plików, takie jak: ext4: domyślny system plików w większości dystrybucji Linuksa. NTFS: system plików używany w systemach Windows. FAT: popularny w nośnikach przenośnych (pendrive, karty SD). ISO9660: używany w płytach CD/DVD. Różne systemy plików: /proc: Wirtualny system plików używany do dostępu do informacji o procesach i systemie. /mnt: Katalog przeznaczony na tymczasowe punkty montowania, np. urządzenia zewnętrzne. o /mnt/cdrom: Zamontowana płyta CD/DVD (ISO9660). o /mnt/dysk1: Dysk z systemem plików NTFS. o /mnt/floppy: Dyskietka z systemem FAT. /var: Katalog na pliki zmienne, np. logi systemowe lub dane aplikacji. Może korzystać z różnych systemów plików (ext2, ext4). File Systemy – Systemy plików Pierwszy sektor na każdym dysku (CHS=001) to MBR (Master Boot Record - główny sektor bootujący). MBR składa się z dwóch części: I. umieszczonego na początku kodu wykonywalnego II. tablicy partycji. MBR kończy się sygnaturą 55 AA – wskazuje że sektor jest prawidłowy Tablica partycji złożona jest z czterech rekordów o długości 16 bajtów każdy W rekordach może być zapisana informacja maksymalnie o czterech partycjach podstawowych (albo o maksymalnie trzech partycjach podstawowych i jednej rozszerzonej). Każdy rekord ma następującą strukturę: ▪ pierwszy bajt określa stan partycji (aktywna to 80, nieaktywna to 00) ▪ trzy bajty (nr 2, 3, 4) to adres początkowy w formacie CHS (Cylinder-Head-Sector). ▪ piąty bajt to identyfikator (ID), który określa typ partycji (FAT, NTFS, ext2, itp.) ▪ trzy następne bajty (nr 6, 7, 8) to adres końcowy w formacie CHS ▪ cztery bajty (nr 9, 10, 11) to podana w sektorach odległość między początkiem dysku a początkiem partycji ▪ ostatnie cztery bajty to rozmiar partycji, określany jako liczba zajmowanych (alokowanych) przez nią sektorów FAT (ang. File Alloccation Table) określa rozmieszczenie plików, katalogów i wolnej przestrzeni na dysku twardym. Tabela ta zawiera spis wszystkich jednostek alokacyjnych (klastrów) całej partycji. Tabela odpowiada za przechowywanie informacji o rozmieszczeniu plików na nośniku. Każda jednostka alokacyjna (klaster) w partycji ma swój wpis w tabeli FAT. Wartości w tabeli FAT wskazują: Numer kolejnego klastra należącego do pliku. Lub specjalne znaczniki (np. koniec pliku, klaster wolny). Kopia FAT - ze względu na dużą wartość informacji przechowywanych w tablicy warto zabezpieczyć się na wypadek zniszczenia oryginalnej tablicy (lub jej części) poprzez duplikacje danych na niej umieszczonych. Wadą jest położenie obu tablic obok siebie! Root directory - jest to katalog główny systemu plików, występuje w ustalonym miejscu w partycji. Zawiera: nazwy plików, daty modyfikacji, atrybuty plików, początkowy klaster pliku w tabeli FAT. Obszar danych - pliki (i katalogi) umieszczone w klastrach (jeden lub więcej klastrów przypadających na plik). Reprezentowane są jako ciąg bajtów, jeśli nie wystarcza klastra kolejne są w następnym itd. Za poprawność operacji następnika odpowiedzialna jest tablica FAT. Katalogi są to pliki specjalnej postaci. Katalog jest podzielony na małe struktury nazywane wpisami. Każdy wpis ma rozmiar 32 bajtów i jest informacją o katalogu bądź pliku, zawartym w naszym katalogu. Wpis zawiera pola: ✓8 bajtów - nazwa pliku, ✓3 bajty - rozszerzenie, ✓1 bajt - atrybuty pliku: read-only, tylko do odczytu / hidden, ukryty / system, plik systemowy / volume label, tak jest oznaczony jeden plik w katalogu głównym, jego nazwa jest nazwą dysku / subdirectory, czy jest to katalog / archive, plik, który trzeba skopiować przy następnej kopi zapasowej / device, plik reprezentuje urządzenie / unused, nie używane ✓1 bajt - wielkość liter nazwy i rozszerzenia pliku, ✓1 bajt - czas utworzenia w milisekundach, ✓2 bajty - czas utworzenia, ✓2 bajty - data utworzenia, ✓2 bajty - czas ostatniego dostępu, ✓2 baty - zarezerwowane, ✓2 bajty - czas utworzenia lub ostatniej modyfikacji pliku, ✓2 bajty - data utworzenia lub ostatniej modyfikacji pliku, ✓2 bajty - numer klastera gdzie rozpoczyna się plik, ✓4 bajty - rozmiar pliku. Limity systemów plików FAT Wady systemów plików FAT ▪ sekwencyjny dostęp do plików ▪ podatność na awarie ▪ nieefektywny na dużych partycjach ▪ ubogie wsparcie dla metadanych (m.in brak uprawnień dla plików) Brakuje jeszcze kilku rzeczy: ▪ więcej informacji o samych danych (metadane) ▪ możliwość ustalania ograniczeń dla poszczególnych użytkowników (quota) ▪ zagwarantowanie bezpieczeństwa danych jak również metadanych ▪ dowiązania symboliczne ▪ wiele strumieni danych ext / ext2 / ext3 / ext4 Ext2 (ang. Second Extended File System) jest podstawowym i najszerzej używanym systemem plików dla Linuxa. Jest bardzo efektywny w typowych zastosowaniach, a równocześnie stosunkowo prosty. Jest uważany za jeden z najlepszych "standardowych" systemów plików. ▪ Zapewnia wszystkie elementy systemu plików Unix (dowiązania symboliczne, pliki specjalne, prawa dostępu...) ▪ Wysoka wydajność dzięki przeciwdziałaniu fragmentacji (poprzez przydzielanie bliskich bloków oraz prealokację) ▪ Wydajny mechanizm dowiązań symbolicznych ▪ Stabilny i dobrze przetestowany ▪ Dobrze zdefiniowany sposób dodawania rozszerzeń ▪ Niezależny od tworzącego systemu operacyjnego (wszystkie pola wielobajtowe zapisane w standardzie little-endian) ▪ Maksymalny rozmiar partycji to 4TB, a pojedynczego pliku 2GB. Maksymalna długość nazwy pliku: 255 znaków. ▪ Obsługa "dziurawych" plików (nieużywane bloki nie zostają przydzielone). Partycja systemu plików Ext2 podzielona jest na bloki o rozmiarze 1024, 2048 lub 4096 bajtów. Kolejne bloki połączone są w grupy, których rozmiar zależy od wybranego rozmiaru bloku. Grupa składa się z: Superbloku – opisujący cały system plików Deskryptorów grup – opisujące sumaryczne informacje o wszystkich grupach Mapy bitowej bloków – każdy bit mapy odpowiada jednemu blokowi, jeśli jest ustawiony to blok jest zajęty Mapa bitowa i-węzłów – opisuje zajętość i-węzłów w danej grupie Tablica i-węzłów – bloki, w ramach których przydzielane są metryczki plików (i-węzły) Bloków danych Superblok 1. Rozmiar bloku 2. Liczby wszystkich oraz wolnych bloków i i-węzłów 3. Stan systemu plików (czy został poprawnie zamknięty) 4. Licznik zamontowań i data ostatniego sprawdzenia - pozwalają wymusić sprawdzenie integralności danych co pewien czas 5. Wersja systemu plików - zbiór 3 różnych kategorii rozszerzeń, w zależności od stopnia wprowadzanych przez nie niezgodności: ▪ COMPAT - zmiany należące do tej kategorii są zupełnie przejrzyste dla starszych wersji ▪ RO_COMPAT - zmiany te nie powodują błędów przy odczycie, ale zapis w takim systemie przez wersję nie obsługującą rozszerzenia spowodowałby uszkodzenie danych. Stara wersja może używać takiej partycji w trybie tylko do odczytu ▪ INCOMPAT - wprowadzone zmiany są na tyle poważne, że próba użycia systemu plików przez starszą wersję może skończyć się błędem. Deskryptory grup Jest to tablica rekordów, po jednym dla każdej grupy, opisujących sumaryczne dane (m.in. liczbę wolnych i-węzłów i bloków). Informacje te są używane podczas przydzielania bloków. I-węzły I-węzeł opisuje wszystkie atrybuty obiektu zapisanego w systemie plików, poza jego nazwą. Są to: Dowiązania do bloków danych (12 bezpośrednich i po jednym pojedynczo, podwójnie i potrójnie pośrednim) Prawa dostępu Właściciel (użytkownik i grupa) Typ obiektu i różne flagi Rozmiar obiektu i liczba używanych przez niego bloków Data dostępu, modyfikacji, zmiany metadanych i skasowania obiektu Liczba dowiązań (wpisów katalogu odwołujących się do tego i-węzła) Dodatkowe informacje (wersja, Access Control List, Extended Attributes) Katalogi Są zorganizowane jako standardowe pliki rekordów zmiennej długości. Zapisane są więc w tej samej przestrzeni, co bloki zwykłych plików. Każdy rekord zawiera pole określające jego długość, co pozwala "przeskakiwać" nad dziurami powstałymi po usunięciu krótkich wpisów. Poza tym rekordy zawierają nazwę pliku oraz numer jego i-węzła. W nowszych wersjach systemu Ext2 także typ obiektu (plik, katalog, plik specjalny, dowiązanie symboliczne) zapisywany jest w katalogu. Pozwala to ograniczyć liczbę wczytywanych i-węzłów w operacjach przeszukiwania katalogu. ext3 Udostępnia trzy sposoby journallingu: samych metadanych danych i metadanych samych metadanych, ale z wcześniejszym zapisywaniem bloków danych (zwany ordered, jest to sposób domyślny) ext4 Zwiększono wydajność operacji dyskowych poprzez umożliwienie operowania na większej liczbie bloków Funkcja ext2 ext3 ext4 Dziennik (journal) Brak Obecny Obecny Maks. rozmiar pliku 2 TB 2 TB 16 TB Maks. rozmiar systemu plików 4 TB 4 TB 1 EB Fragmentacja Wysoka Wysoka Zredukowana dzięki extents Obsługa extents Brak Brak Tak Opóźnione alokowanie Brak Brak Tak Wsteczna kompatybilność Tak Tak Tak Linux – montowanie FS ❖ /etc/fstab – pliki konfiguracyjne które pozwalają montować wybrane FileSystemy w zdefiniowanych punktach. Definiuje: lokalizację urządzenia, punkt montowania, typ systemu plików, opcje montowania, priorytet dla sprawdzania integralności systemu plików. ❖ /etc/mtab – aktualnie zainstalowane FileSystemy, wypełniany automatycznie przez system. Służy do weryfikacji zamontowanych systemów plików bez użycia dodatkowych komend. ❖ Punkty montowania specjalnych typów (/sys, /proc, /dev, …) /proc: Wirtualny system plików, umożliwia dostęp do informacji o procesach i systemie. /sys: Wirtualny system plików dla informacji o urządzeniach. /dev: Katalog urządzeń, np. dysków, napędów CD. Linux – /proc ❑ Historycznie wprowadzony do Unixa – „Processes as Files” ❑ Dostęp do jądra oraz parametrów przez pliki ❑ Czysto wirtualne pliki – nie istnieją na dyskach ❑ W większości są to pliki tekstowe ❑ Modyfikacja plików zmienia parametry jądra Każdy proces jest reprezentowany przez identyfikator procesu (PID) w katalogu /proc/PID/ zawierający dużo użytecznych informacji, jak: Plik/Katalog Opis cwd Symboliczny link do bieżącego katalogu roboczego procesu. exe Link do wykonywalnego pliku procesu. environ Zmienne środowiskowe procesu. fd/ Katalog z odnośnikami do otwartych plików. maps Informacje o mapowaniu pamięci procesu. status Szczegółowe dane o stanie procesu, jego PID, PPID, zasobach. Jeśli potrzebujesz więcej informacji o konkretnych plikach lub funkcjonalnościach /proc, daj znać! W Linuksie /proc nie tylko dostarcza informacji o procesie ale również daje dostęp do parametrów jądra Od tej pory naciśnięcie klawiszy Ctrl+Alt+Del spowoduje reakcję jakby nacisnąć fizyczny przycisk RESET – natychmiastowe uruchomienie komputera bez odmontowania FileSystemów, oczyszczenie buforów dyskowych itp. Linux POSIX/ext system plików Dyskowa partycja składa się z bloków (typowo 1 kB) Każdy plik jest reprezentowany przez i-node, dane zawierające najważniejsze informacje o pliku (ale nie jego nazwę!) Katalog to plik zawierający odnośniki do i-node’w i nazw plików Jeśli więcej niż jeden katalog używa i-node’a danego pliku to kasowanie tego pliku zmniejsza jedynie licznik w tym i-node’ie i tylko usuwa informacje w katalogu – nie kasuje i-node’a Gdy ostatni wpis w katalogu, danego pliku, zostanie skasowany i licznik w i-node’ie osiągnie zero to i-node jest kasowany Metadane przechowywane w i-węźle: 1. Rozmiar pliku. 2. Typ pliku (plik regularny, katalog, link symboliczny). 3. Prawa dostępu. 4. UID i GID (właściciel i grupa pliku). 5. Daty: utworzenia, modyfikacji, ostatniego dostępu. 6. Liczba dowiązań (linków) do pliku. 7. Adresy bloków danych, które przechowują zawartość pliku. Struktura katalogu - Katalog w systemie plików ext jest specjalnym rodzajem pliku, który zawiera wpisy wskazujące na i-węzły. Każda nazwa pliku w katalogu jest powiązana z unikalnym identyfikatorem i-węzła. i-node (i-węzeł) - struktura i-node zawiera zestaw (10) wpisów w blokach danych (direct pointers); Sumarycznie jest to blok danych - 1kB, dostęp do małej ilości danych (do 10 kB) jest szybki i prosty Wewnątrz są jeszcze trzy pola: indirect pointers pierwszego, drugiego i trzeciego poziomu Pierwszy poziom (indirect pointer) zawiera zestaw bloków, które nie są traktowane jak bloki danych pliku, ale w zamian zawierają direct pointers do bloków danych Drugi i trzeci poziom zbudowane są analogicznie jak pierwszy Oznacza to skomplikowany i długi dostęp do dużych plików Twarde dowiązania (Hard links) i-węzły ułatwiają twarde dowiązania w obrębie tego samego urządzenia (np. twardy dysk) Różne katalogi mogą zawierać wskaźniki do tego samego i-węzła ale mogą mieć różne nazwy Twarde dowiązanie tworzymy komendą ln : Dwa pliki w katalogach, różnie nazwane: /etc/passwd i /home/stud/all_accounts , zawierają odnośniki do tego samego i-węzła (przykład #444, następny slajd) Symboliczne (miękkie) dowiązania (Symbolic (Soft) links) Symboliczny link to plik tekstowy zawierający ścieżkę dostępu do pliku źródłowego, łatwo rozpoznać po parametrze „l” kiedy wyświetlamy zawartość katalogu komendą „ls –l”. Użyteczne gdy przekraczamy granice jednego systemu plików Wolniejsze i wrażliwe na usunięcie/przeniesienie pliku źródłowego Dwa istniejące pliki, nawet w dwóch różnych systemach plików /etc/passwd jest identyfikowane przez nazwę i ścieżkę niż przez i-węzeł Jeśli /etc/passwd zostanie usunięte to /home/stud/symlink cały czas istnieje ale odnosi się do nieistniejącej lokacji W6 UNIX, Linux i Android – II Linux shell Tradycyjny CLI (Command Line Interface) do systemów Unix I podobnych Program pomiędzy jądrem/bibliotekami OS i użytkownikiem Najważniejsze: Bourne shell (sh) i C shell (csh) Współcześnie: Bourne-Again SHell (bash) i wiele innych (ash, ksh, busybox, …) Spis shell’i dostępny w systemie w: /etc/shells Linux shell: konfiguracja Plik /etc/passwd – ostatnia kolumna w definicji konta zawiera domyślną ścieżkę użytkownika: shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown s127227:x:1002:103::/home/s127227:/bin/bash stud:x:1000:100:,,,:/home/stud: none (empty) W tym wypadku (brak definicji shell’a) uruchomiony będzie domyślny shell. Zła ścieżka lub brak dostępu do systemu dla danego użytkownika: [email protected]'s password:*** Access denied Prawie każdy program może być shell’em Nawet skrypt shell’a może być shell’em W przykładzie: po pomyślnym zalogowaniu wyświetlana jest wiadomość a następnie zakończenie połączenia. Bourne-Again shell (bash) Typowo oznaczenie użytkownika różni się gdy zalogowany jest superuser (uid=0) bash wyświetla wtedy ‘#’, kiedy zalogowany jest zwykły użytkownik widzimy ‘$’. (można również zdefiniować własny wzorzec). Należy bardzo uważać przy wykonywaniu niektórych komend (np. rm * ) gdy widoczny jest #! W przykładach widać: # fdisk /dev/hdb ‘#’ znak oznacza że superuser może wykonać tę komendę; lub ~$ ls -l ta komenda wykonana jest w domowym katalogu przez użytkownika bez uprawnień root’a. (dzisiaj: użyjemy sudo) I/O Przekierowanie Stosując CLI użytkownik używa klawiatury jako urządzenia wejściowego a monitora jako wyjściowego. Zamiast tych urządzeń można korzystać z innych urządzeń „tekstowych” jak port szeregowy czy połączenie sieciowe. To są standardowe urządzenia WE/WY (ang. I/O) (stdio). Pliki tekstowe mogą być wykorzystane jako wejście jak i wyjście – jest to Przekierowanie. Działające programy (procesy) mogą wymieniać dane w ten sposób – standardowe wyjście jednego może być połączone ze standardowym wejściem drugiego. Zestaw tak połączonych programów nazywamy potokiem (pipe). Niektóre programy mogą mieć przekierowane zarówno wejścia jak i wyjścia a dodatkowo wykonywać operacje na tych danych. Nazywane są filtrami. Kilka popularnych filtrów: sort, awk, grep, head, tail Skrypty bash logowania W momencie gdy użytkownik loguje się, lub wylogowuje, do systemu lub uruchamia kolejną kopię shell’a, bash próbuje wykonać różne skrypty: /etc/profile; ~/.profile; ~/.bash_profile; ~/.bash_login; ~/.bash_logout; ~/.bashrc Użytkownik może spersonalizować lokalne skrypty (te umieszczone w katalogu ~ (home))..bash_profile Dodanie do zmiennej PATH ścieżki ~/bin wyszukiwania przed innymi katalogami. Katalogi oddzielone są znakiem ‘:’. Przed dodaniem testowane jest istnienie katalogu ~/bin. Powiązania klawiszy (Key binds) Komenda bind zmienia właściwości klawiatury w shell’u. Użytkownik może łatwo zmienić znaczenie klawiszy na inne jak również zdefiniować całe komendy wprowadzane kombinacją klawiszy. Bardzo przydatne gdy mamy klawiaturę z innym układem klawiszy (np. ‘Z’ zamienione z ‘Y’). Aliasy w bash’u Podobne do wykonywanych skryptów ale wykonywane w bieżącym shell’u; Wykonywane znacznie szybciej i używające bieżących zmiennych shell’a. Wildcards w shell’u Co to jest proces? Uruchomiona instancja pliku wykonywalnego z dysku; Jednostka w SO z własnymi środowiskiem, pamięcią, która może wykonywać kod wykorzystując zasoby; Każdy proces „ma wrażenie” że posiada własny procesor i pamięć. Procesy Linuxa Wykonywalne pliki (programy, skrypty) posiadają ustawiony bit +X (eXecutable); Z punktu widzenia użytkownika wykonanie programu to załadowanie pliku do pamięci komputera poprzez kliknięcie lub wpisanie jego nazwy; SO alokuje zasoby (pamięć, CPU, …) i okresowo daje dostęp do zasobów procesora; System może zatrzymać wykonywanie procesu w dowolnym momencie i uruchomić inny w tym czasie. Proces nie ma nad tym kontroli; Kiedy procesy (zadania) przełączane są często użytkownik ma wrażenie że zadania działają równocześnie, nawet gdy jest tylko jeden CPU (jeden rdzeń). Zarządzanie pamięcią Proces musi być ładowany i wyładowywany z pamięci Każdy proces ma swoje wymagania dotyczące pamięci Każdy proces może być załadowany do innej części pamięci, która generalnie nie jest znana w czasie kompilacji Mechanizm segmentacji wprowadza dodatkowy parametr (adres bazowy) do procesu. Wewnątrz procesu offset do adresu bazowego jest używany jako adres Dodatkowe zabezpieczenie jest potrzebne w związku z pamięcią: dolny i górny limit pamięci każdego procesu Fizyczny adres może być użyty ale musi być ciągłość pamięci każdego procesu Problem: fragmentacja pamięci czy czasochłonna relokacja Zarządzanie pamięcią: Stronicowanie (Paging) Z dodatkowym hardware’owym wsparciem (wydajność!) stronicowanie jest optymalnym rozwiązaniem Fizyczna pamięć jest dzielona na bloki MMU (memory management unit) tłumaczy fizyczne adresy na ciągłą wirtualną przestrzeń adresową Każdy proces „widzi” tylko własną przestrzeń adresową Stronicowanie i wymiana Mechanizm stronicowania pozwala w łatwy sposób zaimplementować mechanizm wymiany pamięci (memory swapping) Część pamięci (strona), która jest stosunkowo rzadko używana, może być przechowywana poza RAM (na HDD) Przechowywać można w pliku (np. Windows pagefile.sys) albo na partycji (Linux swap) Kiedykolwiek proces próbuje użyć pamięci przechowywanej na dysku pojawia się wyjątek hardware’owy i SO ładuje brakującą stronicę z dysku Diagram stanów procesu w Linuxie 1. Running (user-mode) [Stan ①] Proces jest aktualnie wykonywany przez procesor w trybie użytkownika. W trybie użytkownika proces wykonuje kod aplikacji, nie mając bezpośredniego dostępu do sprzętu. 2. Running (kernel-mode) [Stan ②] Proces wykonuje operacje w trybie jądra. Jest to sytuacja, gdy proces wykonuje wywołanie systemowe (np. odczyt pliku) lub obsługuje przerwanie. Proces przechodzi do tego stanu z trybu użytkownika. 3. Ready (RAM) [Stan ③] Proces jest gotowy do wykonania, ale czeka w kolejce, ponieważ procesor jest zajęty. Dane procesu znajdują się w pamięci RAM. 4. Sleeping (RAM) [Stan ④] Proces czeka na zakończenie operacji wejścia/wyjścia lub sygnał. Jego dane są przechowywane w pamięci RAM. 5. Ready (swap) [Stan ⑤] Proces jest gotowy do wykonania, ale jego dane zostały przeniesione do pamięci wymiany (swap), aby zwolnić miejsce w RAM. 6. Sleeping (swap) [Stan ⑥] Proces oczekuje na zdarzenie (np. zakończenie operacji wejścia/wyjścia), ale jego dane zostały przeniesione do pamięci wymiany. 7. Switching (kernel→user mode) [Stan ⑦] Proces przechodzi z trybu jądra (kernel mode) do trybu użytkownika (user mode) po zakończeniu wywołania systemowego. 8. Created [Stan ⑧] Proces został utworzony (np. przez wywołanie fork()), ale jeszcze nie rozpoczął działania. Jest w fazie inicjalizacji. 9. Zombie [Stan ⑨] Proces zakończył działanie, ale jego wpis w tablicy procesów wciąż istnieje, ponieważ rodzic jeszcze nie odebrał statusu zakończenia procesu. Proces zombie nie zużywa zasobów systemowych (oprócz wpisu w tablicy procesów). Procesy i sygnały Wysyłanie sygnału: komenda kill , funkcja kill() lub skrypt killall Najczęściej używane sygnały: SIGKILL – zamyka proces SIGHUP – zawieszenie procesu (kończenie działania procesu) SIGTERM – zakończenie działania programu SIGSTOP – zatrzymuje proces – podobnie jak SIGKILL SIGCONT – uruchamia (restartuje) proces SIGUSR1, SIGUSR2 – sygnały użytkownika SIGINT – (Ctrl + C) – przerywa proces SIGALARM – może być ustawiony z funkcji alarm() Linux Dostęp do urządzeń u Linuxie Najważniejsza zasada w systemie – wszystko traktowane jest jak plik. Przykład – podłączenie myszki do Linuxa z nakładką okienkową Myszka musi być podłączona do komputera fizycznie przez port USB (parametry elektryczne i usb host – wymiana komunikatów) Podsystem odpowiedzialny za USB obsługuje magistralę USB, przekazując dane odebrane od urządzeń odpowiednim sterownikom Podsystem wejścia (myszka jest urządzeniem wejścia) przechwytuje dane odebrane z magistrali i tłumaczy je na odpowiednie ciągi bajtów, które pojawią się jako ruch myszy w pliku /dev/input/eventX (X to numer odpowiadający myszce). Format jest ściśle ustalony. W przestrzeni użytkownika program otwiera taki plik i odczytuje z niego dane. Zwykle jest to Xorg, który wyświetla kursor i przekazuje informacje o zdarzeniach do poszczególnych aplikacji Aplikacje okienkowe odbierają od serwera grafiki pojedyncze zdarzenia z informacjami o ruchach i kliknięciach myszy Większość urządzeń jest reprezentowana przez pliki w katalogu /dev Zmiana parametrów sterowników – wirtualny system plików /sys Pliki w katalogu /sys pozwalają sterować urządzeniami, dotyczy to urządzeń nie występujących w katalogu /dev (np. karty sieciowe). W katalogu /sys mamy kilka podkatalogów (grup): block – lista urządzeń blokowych, takich jak dyski i inne nośniki pamięci, w tym urządzenia ramdysku bus – urządzenia podzielone wg magistrali, do której są wpięte (np. usb, i2c…) class – urządzenia rozdzielone wg ich typu dev – głównie katalogi określające urządzenie po liczbie major i minor fs – obsługa sterowników systemu plików module – poszczególne sterowniki systemu (moduły jądra) Przykład zmiany trybu karty sieciowej z eth0 na PROMISCOUS (umożliwia akceptowanie wszystkich pakietów nie tylko tych przeznaczonych dla niej). W katalogu /sys/class/net/eth0 wybieramy plik flags (zazwyczaj wartość 0x1003) Flagi (nazwy można znaleźć w plikach nagłówkowych /usr/include grep −R ”PROMISC” /usr/include/ ): IFF_UP = 0x1 (interfejs jest włączony) IFF_BROADCAST = 0x2 (interfejs akceptuje pakiety przesyłane na adres rozgłoszeniowy) IFF_MULTICAST = 0x1000 (interfejs akceptuje pakiety typu multicast) Dodajemy flagę: IFF_PROMISC (0x100) Obliczoną wartość można wpisać bezpośrednio do pliku z konsoli lub funkcją fprintf Linux – prosta komunikacja z urządzeniami I/O Komunikacja z urządzeniami przez odczyt/zapis (dyski, porty, przesyłanie danych) Wystarczą funkcje: open, read, write, close Przykład – odczyt kodów aktualnie wciskanych klawiszy – plik /dev/input/eventX Odczyt klawiszy typu Shift jest trudny z poziomu zwykłego procesu a w wypadku gdy okno jest nieaktywne to niemożliwy. Poprzez pliki w /dev/input dostęp jest prosty. Opis danych generowanych przez urządzenie z katalogu /dev/input, które reprezentują pojedyncze zdarzenia w systemie. Znacznik czasu kiedy zdarzenie miało miejsce, jego typ oraz wartość Android Organizacja systemu Android jest systemem z rodziny Linuxa dla systemów wbudowanych ale z dużymi zmianami. ❖ System przeznaczony dla jednego użytkownika ❖ Android aplikacje pisane w Javie/Kotlin’ie – Linux aplikacje pisane w C/C++ ❖ Android – wirtualna maszyna Javy ❖ Jednolite API bez względu na sprzęt (ograniczenie w dostępie do niższych warstw systemu) ❖ Android = identyfikatory aplikacji – Linux = identyfikatory użytkowników/grup (w tym prawa dostępu) Interfejs programistyczny aplikacji (ang. Application Programming Interface, API) – sposób, rozumiany jako ściśle określony zestaw reguł i ich opisów, w jaki programy komunikują się między sobą. API definiuje się na poziomie kodu źródłowego dla takich składników oprogramowania jak np. aplikacje, biblioteki czy system operacyjny. Zadaniem API jest dostarczenie odpowiednich specyfikacji podprogramów, struktur danych, klas obiektów i wymaganych protokołów komunikacyjnych. 1. Linux kernel – jądro systemu odpowiadające za komunikację ze sprzętem, zarządza procesami, zabezpiecza dostęp do poszczególnych części systemu. 2. Libraries – programy które muszą być uruchomione do prawidłowego działania Linuxa oraz Androida. 3. Dalvik (wirtualna maszyna) – udostępnia jednolite API dla uruchamianych programów oraz zapewnia dostęp do sprzętu i usług. 4. Applications – paczki APK, które zawierają kod wykonywany przez wirtualną maszynę Dalvik System plików Pierwsza, główna, partycja (w pamięci RAM) – specjalny system plików rootfs – zawartość jest kopiowana z pamięci flash w czasie startu systemu. Partycja /system – zawiera aplikacje niezbędne do działania wyższych warstw systemu, pliki konfiguracyjne, część aplikacji. Znajdują się tu również katalogi: /system/bin , /system/etc , /system/lib. Katalog /data – wszystkie ustawienia aplikacji oraz rzeczy, które mogą się zmieniać w trakcie ich działania. Katalog ten jest zawsze w trybie do odczytu i zapisu. W tym katalogu znajdują się: ▪ /data/data – dane i pliki konfiguracyjne użytkownika ▪ /data/app – paczki APK (aplikacje użytkownika instalowane w pamięci urządzenia) ▪ /data/system – pliki systemowe (konfiguracyjne) Katalog /cache – pliki tymczasowe (również zawsze w trybie do odczytu i zapisu). Katalog /mnt/sdcard – zwykle montowana jest karta SD Aplikacja w Androidzie i jej życie Od systemu w wersji 9 – Android zamyka aplikacje, które nie są używane. Od systemu w wersji 11 – opcja na nadawanie uprawnień jednorazowych. Od systemu w wersji 12 - większa prywatność (pytanie o dostęp do aparatu i rejestratora dźwięku) - ograniczenie transferu danych - hibernacja aplikacji

Use Quizgecko on...
Browser
Browser