%% intro.tex
%%
-%% Copyright (C) 2000-2005 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{L'architettura del sistema}
\label{cha:intro_unix}
cosiddetto \textit{kernel}, nel nostro caso Linux) a cui si demanda la
gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre
tutto il resto, quindi anche la parte che prevede l'interazione con l'utente,
-deve venire realizzato tramite programmi eseguiti dal kernel e che accedano
+dev'essere realizzato tramite programmi eseguiti dal kernel, che accedano
alle risorse hardware tramite delle richieste a quest'ultimo.
Fin dall'inizio uno Unix si presenta come un sistema operativo
(e non possono accedere direttamente alle zone di memoria riservate o alle
porte di input/output).
-Una parte del kernel, lo \textit{scheduler}\index{\textit{scheduler}}, si
-occupa di stabilire, ad intervalli fissi e sulla base di un opportuno calcolo
-delle priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione
-(il cosiddetto \textit{preemptive
- scheduling}\index{\textit{preemptive~scheduling}}). Questo verrà comunque
-eseguito in modalità protetta; quando necessario il processo potrà accedere
-alle risorse hardware soltanto attraverso delle opportune chiamate al sistema
-che restituiranno il controllo al kernel.
+Una parte del kernel, lo \itindex{scheduler} \textit{scheduler}, si occupa di
+stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
+priorità, quale ``\textsl{processo}'' deve essere posto in esecuzione (il
+cosiddetto \itindex{prehemptive~multitasking} \textit{prehemptive
+ multitasking}). Questo verrà comunque eseguito in modalità protetta; quando
+necessario il processo potrà accedere alle risorse hardware soltanto
+attraverso delle opportune chiamate al sistema che restituiranno il controllo
+al kernel.
La memoria viene sempre gestita dal kernel attraverso il meccanismo della
\textsl{memoria virtuale}\index{memoria~virtuale}, che consente di assegnare a
in esame la procedura di avvio di un sistema unix-like; all'avvio il BIOS (o
in generale il software di avvio posto nelle EPROM) eseguirà la procedura di
avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da
- un espressione gergale che significa ``sollevarsi da terra tirandosi per le
+ un'espressione gergale che significa ``sollevarsi da terra tirandosi per le
stringhe delle scarpe'', per indicare il compito, almeno apparentemente
impossibile, di far eseguire un programma a partire da un computer appena
- acceso che appunto non ne contiene nessuno; non è impossibile appunto perché
- in realtà c'è un programma iniziale, che è appunto il BIOS.}), incaricandosi
-di caricare il kernel in memoria e di farne partire l'esecuzione;
-quest'ultimo, dopo aver inizializzato le periferiche, farà partire il primo
-processo, \cmd{init}, che è quello che a sua volta farà partire tutti i
-processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare
-con la tastiera e lo schermo della console, e quello che mette a disposizione
+ acceso che appunto non ne contiene nessuno; non è impossibile perché in
+ realtà c'è un programma iniziale, che è il BIOS.}), incaricandosi di
+caricare il kernel in memoria e di farne partire l'esecuzione; quest'ultimo,
+dopo aver inizializzato le periferiche, farà partire il primo processo,
+\cmd{init}, che è quello che a sua volta farà partire tutti i processi
+successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la
+tastiera e lo schermo della console, e quello che mette a disposizione
dell'utente che si vuole collegare, un terminale e la \textit{shell} da cui
inviare i comandi.
Questo è importante da capire perché programmare in Linux significa anzitutto
essere in grado di usare le varie interfacce contenute nella Libreria Standard
-del C, in quanto né il kernel, né il linguaggio C, implementano direttamente
+del C, in quanto né il kernel, né il linguaggio C implementano direttamente
operazioni comuni come l'allocazione dinamica della memoria, l'input/output
bufferizzato o la manipolazione delle stringhe, presenti in qualunque
programma.
\textit{default group}), ma può essere associato ad altri gruppi (i
\textit{supplementary group}), questo permette di gestire i permessi di
accesso ai file e quindi anche alle periferiche, in maniera più flessibile,
-definendo gruppi di lavoro, di accesso a determinate risorse, etc.
+definendo gruppi di lavoro, di accesso a determinate risorse, ecc.
L'utente e il gruppo sono identificati da due numeri, la cui corrispondenza ad
un nome espresso in caratteri è inserita nei due file \file{/etc/passwd} e
in sez.~\ref{sec:sys_user_group} queste informazioni possono essere
mantenute, con l'uso del \textit{Name Service Switch}, su varie tipologie di
supporti, compresi server centralizzati come LDAP.}
-\index{\textit{Name~Service~Switch}} Questi numeri sono l'\textit{user
- identifier}, detto in breve \textsl{user-ID}, ed indicato dall'acronimo
-\acr{uid}, e il \textit{group identifier}, detto in breve \textsl{group-ID},
-ed identificato dall'acronimo \acr{gid}, e sono quelli che vengono usati dal
-kernel per identificare l'utente.
+\itindex{Name~Service~Switch} Questi numeri sono l'\textit{user identifier},
+detto in breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il
+\textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato
+dall'acronimo \acr{gid}, e sono quelli che vengono usati dal kernel per
+identificare l'utente.
In questo modo il sistema è in grado di tenere traccia dell'utente a cui
appartiene ciascun processo ed impedire ad altri utenti di interferire con
essere in grado di fare qualunque operazione; per l'utente \textit{root}
infatti i meccanismi di controllo descritti in precedenza sono
disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
- del tipo \code{if (uid) \{ ... \}}}
+ del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
\section{Gli standard}
Uno dei problemi di portabilità del codice più comune è quello dei tipi di
dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
-anche da una architettura ad un altra (ad esempio passando da macchine con
+anche da una architettura ad un'altra (ad esempio passando da macchine con
processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
\textit{tipi elementari}\index{tipo!elementare} del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
\textbf{Tipo} & \textbf{Contenuto} \\
\hline
\hline
- \type{caddr\_t} & core address.\\
- \type{clock\_t} & contatore del tempo di sistema.\\
+ \type{caddr\_t} & Core address.\\
+ \type{clock\_t} & Contatore del tempo di sistema.\\
\type{dev\_t} & Numero di dispositivo.\\
\type{gid\_t} & Identificatore di un gruppo.\\
\type{ino\_t} & Numero di \textit{inode}\index{inode}.\\
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
-i comandi di sistema (1003.2), per le estensioni realtime e per i thread
-(1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
+i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
+thread (1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
riportata una classificazione sommaria dei principali documenti prodotti, e di
come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate
ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i
\textit{thread} (vedi cap.~\ref{cha:threads}), e dallo standard POSIX.1b per
-quanto riguarda i segnali e lo scheduling real-time
+quanto riguarda i segnali e lo \itindex{scheduler} scheduling real-time
(sez.~\ref{sec:sig_real_time} e sez.~\ref{sec:proc_real_time}), la misura del
tempo, i meccanismi di intercomunicazione (sez.~\ref{sec:ipc_posix}) e l'I/O
asincrono (sez.~\ref{sec:file_asyncronous_io}).
-\subsection{Lo standard X/Open -- XPG3}
+\subsection{Lo standard X/Open}
\label{sec:intro_xopen}
Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi
Specification}, SUSv1, più comunemente nota come \textit{Unix 95}.
-\subsection{Gli standard Unix -- Open Group}
+\subsection{Gli standard Unix}
\label{sec:intro_opengroup}
Nel 1996 la fusione del consorzio X/Open con la Open Software Foundation (nata
da un gruppo di aziende concorrenti rispetto ai fondatori di X/Open) portò
-alla costituzione dell'Open Group, un consorzio internazionale che raccoglie
-produttori, utenti industriali, entità accademiche e governative.
+alla costituzione dell'\textit{Open Group}, un consorzio internazionale che
+raccoglie produttori, utenti industriali, entità accademiche e governative.
Attualmente il consorzio è detentore del marchio depositato Unix, e prosegue
il lavoro di standardizzazione delle varie implementazioni, rilasciando
alle stesse.
Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
- Specification}, nota con la sigla SUSv2, in queste versione le interfacce
+ Specification}, nota con la sigla SUSv2, in questa versione le interfacce
specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
grafiche, per le quali sono inserite pure le interfacce usate da CDE che
richiede sia X11 che Motif). La conformità a questa versione permette l'uso
\label{sec:intro_bsd}
Lo sviluppo di BSD iniziò quando la fine della collaborazione fra l'Università
-di Berkley e la AT\&T generò una delle prime e più importanti fratture del
+di Berkeley e la AT\&T generò una delle prime e più importanti fratture del
mondo Unix. L'Università di Berkley proseguì nello sviluppo della base di
codice di cui disponeva, e che presentava parecchie migliorie rispetto alle
versioni allora disponibili, fino ad arrivare al rilascio di una versione
della AT\&T.
Benché BSD non sia uno standard formalizzato, l'implementazione di Unix
-dell'Università di Berkley, ha provveduto nel tempo una serie di estensioni e
+dell'Università di Berkeley, ha provveduto nel tempo una serie di estensioni e
API di grande rilievo, come i link simbolici, la funzione \code{select} ed i
socket.
definendo opportune costanti prima dell'inclusione dei file degli header.
Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
-si può usare l'opzione \cmd{-ansi} del compilatore, e non sarà riconosciuta
-nessuna funzione non riconosciuta dalle specifiche standard ISO per il C.
+si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
+utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
+il C.
Per attivare le varie opzioni è possibile definire le macro di preprocessore,
che controllano le funzionalità che le \acr{glibc} possono mettere a
\end{basedescript}
In particolare è da sottolineare che le \acr{glibc} supportano alcune
-estensioni specifiche GNU, che non sono comprese in nessuno degli
-standard citati. Per poterle utilizzare esse devono essere attivate
-esplicitamente definendo la macro \macro{\_GNU\_SOURCE} prima di
-includere i vari header file.
+estensioni specifiche GNU, che non sono comprese in nessuno degli standard
+citati. Per poterle utilizzare esse devono essere attivate esplicitamente
+definendo la macro \macro{\_GNU\_SOURCE} prima di includere i vari header
+file.
%% \subsection{Gli standard di GNU/Linux}
%% \label{sec:intro_linux_std}
-%% Da fare (o cassare, a seconda del tempo e della voglia).
-
+% TODO Da fare (o cassare, a seconda del tempo e della voglia).
+
+
+
+% LocalWords: like kernel multitasking scheduler prehemptive sez swap is cap
+% LocalWords: everything bootstrap init shell Windows Foundation system call
+% LocalWords: fig libc uClib glibc embedded Library POSIX username PAM Methods
+% LocalWords: Pluggable Autentication group supplementary Name Service Switch
+% LocalWords: LDAP identifier uid gid superuser root if BSD SVr dall' American
+% LocalWords: National Institute International Organisation IEC header tab gcc
+% LocalWords: assert ctype dirent errno fcntl limits malloc setjmp signal utmp
+% LocalWords: stdarg stdio stdlib string times unistd library int short caddr
+% LocalWords: address clock dev ino inode key IPC loff nlink off pid rlim size
+% LocalWords: sigset ssize ptrdiff sys nell'header IEEE Richard Portable of TR
+% LocalWords: Operating Interface dell'IEEE Electrical and Electronics thread
+% LocalWords: Engeneers Socket NT matching regular expression scheduling l'I
+% LocalWords: XPG Portability Issue Application Programmable XTI Transport AT
+% LocalWords: socket Spec Novell Specification SUSv CDE Motif Berkley select
+% LocalWords: SunOS l'AT Sun HP Xenix Description SVID Laboratories MP hsearch
+% LocalWords: drand fmtmsg define SOURCE lbsd compat XOPEN version ISOC Large
+% LocalWords: LARGEFILE Support LFS dell'
%%% Local Variables:
projects / gapil.git / blobdiff