% Impala Operating System
%
% Copyright (C) 2009 University of Wroclaw. Department of Computer Science
%    http://www.ii.uni.wroc.pl/
% Copyright (C) 2009 Mateusz Kocielski, Artur Koninski, Pawel Wieczorek
%    http://bitbucket.org/wieczyk/impala/
% All rights reserved.
%
% Redistribution and use in source and binary forms, with or without
% modification, are permitted provided that the following conditions
% are met:
% 1. Redistributions of source code must retain the above copyright
%  notice, this list of conditions and the following disclaimer.
% 2. Redistributions in binary form must reproduce the above copyright
%  notice, this list of conditions and the following disclaimer in the
%  documentation and/or other materials provided with the distribution.
%
% THIS SOFTWARE IS PROVIDED BY AUTHOR AND CONTRIBUTORS ``AS IS'' AND
% ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
% IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
% ARE DISCLAIMED.  IN NO EVENT SHALL AUTHOR OR CONTRIBUTORS BE LIABLE
% FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
% DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
% OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
% HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
% LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
% OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
% SUCH DAMAGE.
%
% $Id: vfs.tex 577 2009-07-08 04:50:22Z wieczyk $

\section{Pomniejsze usługi jądra.} \label{SERV}

\subsection{Wywołania systemowe.} \label{SYSCALL}

Proces użytkownika nie posiada żadnych efektywnych praw pozwalających mu
na~samodzielne modyfikowanie zawartości plików i katalogów, rozmiaru
używanej przez siebie pamięci czy uruchamianie innych programów - nie posiada
nawet praw pozwalających mu samodzielnie zakończyć swoje działanie.
Wykonanie takich operacji jest zlecane przez użytkownika do~systemu
za~pomocą mechanizmu wywołań systemowych.

Użytkownik przekazuje parametry systemowi kładąc je na~stos, tak jakby
miał wywołać procedurę w~języku C, lecz zamiast instrukcji wywołującej
ustawia numer żądanej operacji w~rejestrze procesora \texttt{eax}
i~uruchamia instrukcję generującą odpowiednie przerwanie
programowe\footnote{W nowoczesnych procesorach są dostarczone specjalne
instrukcje do~obsługi wywołań systemowych, zmniejszające narzut związany
z~obsługą przerwań, na architekturze x86 są to instrukcje \texttt{sysenter} 
oraz \texttt{sysexit}. 
}. Sterowanie zostaje przekazane przez procesor do~procedury
\texttt{ISR\_syscall}, która przekazuje odpowiednio sterowanie dalej
do~procedury \texttt{syscall}, niezależnej już od~platformy sprzętowej.

Po przywróceniu sterowania do~programu w~rejestrze \texttt{eax} znajduje się
wynik operacji, a w~rejestrze \texttt{ecx} numer błędu.

\subsection{Sygnały.} \label{SIGNAL}

Sygnały są podstawowym mechanizmem systemów UNIXowych służącym do powiadamiania 
procesów o zajściu zdarzeń systemowych czy komunikacji między wątkami. Istnieje
wiele niekompatybilnych ze sobą implementacji sygnałów w systemach UNIXowych,
ze względu na spory chaos na tej płaszczyźnie zdecydowaliśmy się na
implementację zgodną ze standardem POSIX wzorowaną na systemach rodziny BSD.

System sygnałów jest bardzo prostym i intuicyjnym mechanizmem, działa on na
zasadzie poinformowania procesu o nadejściu jednego z 32 sygnałów i podjęciu
przez ten proces odpowiedniej akcji. Procesy mogą same decydować co zrobić z
sygnałem, który został do nich dostarczony, możliwe jest podjęcie akcji
domyślnej, zignorowanie sygnału oraz własna obsługa sygnału. Wyjątkiem są
sygnały SIGSTOP i SIGKILL, które nie mogą zostać zignorowane lub zamienione
własną obsługą sygnału. Akcja zapisywana jest w bloku kontrolnym procesu w 
strukturze \texttt{sigaction} odpowiedzialnej za przechowywanie adresu obsługi sygnału.
Adres może przyjmować dwie wartości specjalne \texttt{SIG\_DFL}, \texttt{SIG\_IGN}
odpowiadające odpowiednio domyślnej obsłudze, zignorowaniu sygnału, lub być wskaźnikiem 
na funkcję obsługi sygnału zdefiniowanej w programie przez programistę.
Wielokrotne dostarczenie jednego sygnału do procesu
zanim proces zdąży sygnał obsłużyć jest równoznaczne z jednokrotnym wysłaniem
sygnału. Sygnały w systemie dostarczane są do procesu do bloku kontrolnego
procesu, sygnał może obsłużyć dowolny jego wątek, ustawiając w bloku kontrolnym
jego obsłużenie i następnie podejmując akcje odpowiednią dla niego na podstawie
tablicy \texttt{p\_sigact}. Obsługę
sygnału można rozumieć jako przerwanie działania programu, przechowanie kontekstu, 
wykonanie procedury obsługi a następnie powrót do miejsca, w którym nastąpiło przerwanie i
odtworzenie przechowanego kontekstu.
Sprawdzanie czy nadszedł nowy sygnał realizowane jest przy zmianie kontekstu
oraz powrocie z wywołań systemowych. Ponieważ możliwe jest przerywanie
działania procedur
obsługi sygnałów, to jądro udostępnia specjalny interfejs obsługi sygnałów przez
procedury \texttt{sigenter} i \texttt{sigreturn}, które organizują procedury
obsługi sygnałów w stos działający analogicznie do stosu przy klasycznym wywoływaniu
procedur.

\subsection{Kolejki wiadomości.} \label{SYSVMSG}

Kolejki wiadomości są jednym z~trzech mechanizmów komunikacji między
procesami wywodzącej się z~Systemu V. Obok nich istnieją również mechanizmy
pamięci dzielonej oraz semaforów, nie zostały one jednak zaimplementowane.

Użytkownik identyfikuje zasoby komunikacji między procesami za~pomocą
kluczy, które można porównać z~plikami. Charakteryzują je takie same
prawa dostępu oraz operacje tworzenia i~usuwania.

Znając klucz użytkownik może pobrać identyfikator kolejki wiadomości za~pomocą
której może się wymieniać wiadomościami z~innymi procesami.
