X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=intro.tex;h=23f677bb1247d40881205f2d3805a859d72a86cf;hb=70860564e1de946ab8d681bb41c601ba77721709;hp=dbddfbff95a0f01f642880838504376cf5e54348;hpb=9af45624498d2128e3da65075649a4167e7f6661;p=gapil.git diff --git a/intro.tex b/intro.tex index dbddfbf..23f677b 100644 --- a/intro.tex +++ b/intro.tex @@ -1,6 +1,6 @@ %% 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", @@ -8,6 +8,7 @@ %% license is included in the section entitled "GNU Free Documentation %% License". %% + \chapter{L'architettura del sistema} \label{cha:intro_unix} @@ -62,14 +63,14 @@ all'hardware, mentre i programmi normali vengono eseguiti in modalit (e non possono accedere direttamente alle zone di memoria riservate o alle porte di input/output). -Una parte del kernel, lo \textit{scheduler}\itindex{scheduler}, si occupa di +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 \textit{prehemptive - multitasking}\itindex{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. +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 @@ -117,13 +118,13 @@ avvio del sistema (il cosiddetto \textit{bootstrap}\footnote{il nome deriva da 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. @@ -187,7 +188,7 @@ usate nella programmazione. 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. @@ -517,7 +518,7 @@ 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 @@ -550,13 +551,13 @@ versione di Spec 1170 divent 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 @@ -575,7 +576,7 @@ del nome \textit{Unix 98}, usato spesso anche per riferirsi allo standard. \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 @@ -583,7 +584,7 @@ completa di Unix, chiamata appunto BSD, del tutto indipendente dal codice 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. @@ -707,10 +708,10 @@ Le macro disponibili per i vari standard sono le seguenti: \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} @@ -720,11 +721,6 @@ includere i vari header file. -%%% Local Variables: -%%% mode: latex -%%% TeX-master: "gapil" -%%% End: - % 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 @@ -741,4 +737,10 @@ includere i vari header file. % 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 +% LocalWords: LARGEFILE Support LFS dell' + + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: