From 34ed932cc43ebd3df23ce3255984bba0301b7231 Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 17 Jul 2001 17:49:26 +0000 Subject: [PATCH] La febbre rompe le scatole, ma almeno uno sa come "perdere tempo" --- filedir.tex | 157 ++++++++++++++++++++++++++++++++++++++-------- fileintro.tex | 2 +- gapil.tex | 3 +- img/link_loop.dia | Bin 0 -> 1655 bytes img/vfs.dia | Bin 0 -> 2798 bytes intro.tex | 67 ++++++++++++++++++-- 6 files changed, 195 insertions(+), 34 deletions(-) create mode 100644 img/link_loop.dia create mode 100644 img/vfs.dia diff --git a/filedir.tex b/filedir.tex index 4c2f8d1..0d6dbdb 100644 --- a/filedir.tex +++ b/filedir.tex @@ -13,7 +13,7 @@ dei file Le prime funzioni che considereremo sono quelle relative alla gestione di file e directory, secondo le caratteristiche standard che essi presentano in un -filesystem unix, già esaminate in precedenza (vedi +filesystem unix, la cui struttura abbiamo esaminato in precedenza (vedi \secref{sec:fileintr_filesystem}). \subsection{Le funzioni \texttt{link} e \texttt{unlink}} @@ -89,14 +89,14 @@ filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non il caso ad esempio del filesystem \texttt{vfat} di windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, -ma solo l'amministratore è in grado di creare un collegamento diretto ad -un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti -programmi non sono in grado di gestire e la cui rimozione diventa estremamente -complicata (in genere occorre far girare il programma \texttt{fsck} per -riparare il filesystem); data la sua pericolosità in Linux questa -caratteristica è stata disabilitata, e la funzione restituisce l'errore -\texttt{EPERM}. +in alcuni filesystem solo l'amministratore è in grado di creare un +collegamento diretto ad un'altra directory, questo lo si fa perché in questo +caso è possibile creare dei circoli nel filesystem (vedi +\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di +gestire e la cui rimozione diventa estremamente complicata (in genere occorre +far girare il programma \texttt{fsck} per riparare il filesystem); data la sua +pericolosità in generale nei filesystem usati in Linux questa caratteristica è +stata disabilitata, e la funzione restituisce l'errore \texttt{EPERM}. La rimozione di un file (o più precisamente della voce che lo referenzia) si effettua con la funzione \texttt{unlink}; il suo prototipo è il seguente: @@ -255,10 +255,10 @@ al kernel (analogamente a quanto avviene per le directory) per cui la chiamata ad una \texttt{open} o una \texttt{stat} su un link simbolico comporta la lettura del contenuto del medesimo e l'applicazione della funzione al file specificato da quest'ultimo. Invece altre funzioni come quelle per cancellare -o rinominare i file operano direttamente sul link simbolico. Inoltre esistono -funzioni apposite, come la \texttt{readlink} e la \texttt{lstat} per accedere -alle informazioni del link invece che a quelle del file a cui esso fa -riferimento. +o rinominare i file operano direttamente sul link simbolico (per l'elenco vedi +\ntab). Inoltre esistono funzioni apposite, come la \texttt{readlink} e la +\texttt{lstat} per accedere alle informazioni del link invece che a quelle del +file a cui esso fa riferimento. Le funzioni per operare sui link simbolici sono le seguenti, esse sono tutte dichiarate nell'header file \texttt{unistd.h}. @@ -310,6 +310,87 @@ questa funzione \end{errlist} \end{prototype} +In \ntab\ si è riportato un elenco dei comportamenti delle varie funzioni che +operano sui file rispetto ai link simbolici; specificando quali seguono il +link simbolico e quali possono operare direttamente sul suo contenuto. +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|c|c|} + \hline + Funzione & Segue il link & Non segue il link \\ + \hline + \hline + \func{access} & $\bullet$ & \\ + \func{chdir} & $\bullet$ & \\ + \func{chmod} & $\bullet$ & \\ + \func{chown} & & $\bullet$ \\ + \func{creat} & $\bullet$ & \\ + \func{exec} & $\bullet$ & \\ + \func{lchown} & $\bullet$ & $\bullet$ \\ + \func{link} & & \\ + \func{lstat} & & $\bullet$ \\ + \func{mkdir} & $\bullet$ & \\ + \func{mkfifo} & $\bullet$ & \\ + \func{mknod} & $\bullet$ & \\ + \func{open} & $\bullet$ & \\ + \func{opendir} & $\bullet$ & \\ + \func{pathconf} & $\bullet$ & \\ + \func{readlink} & & $\bullet$ \\ + \func{remove} & & $\bullet$ \\ + \func{rename} & & $\bullet$ \\ + \func{stat} & $\bullet$ & \\ + \func{truncate} & $\bullet$ & \\ + \func{unlink} & & $\bullet$ \\ + \hline + \end{tabular} + \caption{Uso dei link simbolici da parte di alcune funzioni.} + \label{tab:filedir_symb_effect} +\end{table} +si noti che non si è specificato il comportamento delle funzioni che operano +con i file descriptor, in quanto la gestione del link simbolico viene in +genere effttuata dalla funzione che restituisce il file descriptor +(normalmente la \func{open}). + +\begin{figure}[htb] + \centering + \includegraphics[width=5cm]{img/link_loop.eps} + \caption{Esempio di loop nel filesystem creato con un link simbolico.} + \label{fig:filedir_link_loop} +\end{figure} + +Un caso comune che si può avere con i link simbolici è la creazione dei +cosiddetti \textit{loop}. La situazione è illustrata in \curfig, che riporta +la struttura della directory \file{/boot}. Come si vede si è creato al suo +interno un link simbolico che punta di nuovo a \file{/boot}\footnote{Questo + tipo di loop è stato effettuato per poter permettere a \cmd{grub} (un + bootloader estremamente avanzato in grado di accedere direttamente + attraverso vari filesystem al file da lanciare come sistema operativo) di + vedere i file in questa directory, che è montata su una partizione separata + (e che grub vedrebbe come radice), con lo stesso path con cui verrebbero + visti dal sistema operativo.}. + +Questo può causare problemi per tutti quei programmi che effettuassero uno +scan di una directory senza tener conto dei link simbolici, in quel caso +infatti il loop nella directory + +Un secondo punto da tenere presente è che un link simbolico può essere fatto +anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo +nella nostra directory con un link del tipo: +\begin{verbatim} +$ln -s /tmp/tmp_file temporaneo +\end{verbatim}%$ +ma anche se \file{/tmp/tmp_file} non esiste. Aprendo in scrittura +\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola +lettura (ad esempio con \cmd{cat}) otterremmo: +\begin{verbatim} +$ cat prova +cat: prova: No such file or directory +\end{verbatim}%$ +con un errore che sembra sbagliato, dato \cmd{ls} ci mostrerebbe l'esistenza +di \file{temporaneo}. + + \subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}} \label{sec:filedir_dir_creat_rem} @@ -608,20 +689,27 @@ per questo sempre in \texttt{sys/stat.h} sono definiti i flag riportati in Il primo valore definisce la maschera dei bit usati nei quali viene memorizzato il tipo di files, mentre gli altri possono essere usati per -effettuare delle selezioni sul tipo di file voluto. +effettuare delle selezioni sul tipo di file voluto, combinando opportunamente +i vari flag; ad esempio se si volesse controllare se un file è una directory o +un file ordinario si potrebbe definire la condizione: +\begin{lstlisting} +#define IS_FILE_DIR(x) ( ((x) & S_IFMT) & (S_IFDIR | S_IFREG) ) +\end{lstlisting} +in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e +poi si effettua il confronto con la combinazione di tipi scelta. \subsection{La dimensione dei file} \label{sec:filedir_file_size} Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file è un file normale, nel caso di un link simbolico al dimensione è quella del -pathname che contiene, per le directory è in genere un multiplo di 512). +pathname che contiene). Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512 bytes. Il campo \var{st\_blksize} infine definisce la dimensione preferita per i trasferimenti sui file (che è la dimensione usata anche dalle librerie del C -per l'interfaccia deglli stream); scrivere in blocchi di dimensione inferiore -sarebbe inefficiente. +per l'interfaccia degli stream); scrivere sul file a blocchi di dati di +dimensione inferiore sarebbe inefficiente. Si tenga conto che lunghezza del file riportata in \var{st\_size} non è detto che corrisponda all'occupazione dello spazio su disco per via della possibile @@ -637,7 +725,6 @@ legge dal file (ad esempio usando \cmd{wc -c}), dato che in tal caso per le parti non scritte vengono restituiti degli zeri, si avrà lo stesso risultato di \cmd{ls}. - Se è sempre possibile allargare un file scrivendoci sopra od usando la funzione \func{seek} per spostarsi oltre la sua fine. Esistono però anche casi in cui si può avere bisogno di effettuare un troncamento scartando i dati al @@ -647,11 +734,11 @@ Un file pu questo è un caso particolare; per qualunque altra dimensione si possono usare le due funzioni: \begin{functions} - \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off_t + \headdecl{unistd.h} \funcdecl{int truncate(const char *file\_name, off\_t length)} Fa si che la dimensione del file \var{file\_name} sia troncata ad un valore massimo specificato da \var{lenght}. - \funcdecl{int ftruncate(int fd, off_t length))} Identica a \func{truncate} + \funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate} eccetto che si usa con un file aperto, specificato tramite il suo file descriptor \var{fd}, @@ -672,28 +759,46 @@ le due funzioni: Se il file è più lungo della lunghezza specificata i dati in eccesso saranno perduti; il comportamento in caso di lunghezza inferiore non è specificato e -dipende dall'implementazione, il file può essere lasciato invariato o esteso +dipende dall'implementazione: il file può essere lasciato invariato o esteso fino alla lunghezza scelta; in quest'ultimo caso lo spazio viene riempito con zeri (e in genere si ha la creazione di un hole nel file). \subsection{I tempi dei file} \label{sec:filedir_file_times} -Il sistema mantiene tre tempi per ciascun file, corrispondenti a tre campi -della struttura \func{stat}, come riassunto in \ntab: +Il sistema mantiene per ciascun file tre tempi. Questi sono registrati +nell'inode insieme agli altri attibuti del file e possono essere letti tramite +la funzione \func{stat}, che li restituisce attraverso tre campi della +struttura in \figref{fig:filedir_stat_struct} il cui signifato è riportato +nello schema in \ntab: \begin{table}[htb] \centering \begin{tabular}[c]{|c|l|l|c|} - \var{st\_atime} & & & \\ - \var{st\_mtime} & & & \\ - \var{st\_ctime} & & & \\ + \var{st\_atime}& ultimo accesso ai dati del file &\func{read}& \cmd{-u}\\ + \var{st\_mtime}& ultima modifica ai dati del file &\func{write}& default\\ + \var{st\_ctime}& ultima modifica ai dati dell'inode&\func{chmod}, + \func{utime} & \cmd{-c} \\ \end{tabular} \caption{I tre tempi associati a ciascun file} \label{tab:filedir_file_times} \end{table} +La differenza principale di cui tenere presente è quella fra tempo di modifica +\var{st\_mtime} e tempo di cambiamento di stato \var{st\_ctime}. Il primo +infatti fa riferimento ad una modifica del contenuto di un file, mentre il +secondo ad una modifica dell'inode; siccome esistono molte operazioni (come la +funzione \func{link} e molte altre che vedremo in seguito) che modificano solo +le informazioni contenute nell'inode senza toccare il file, dato che queste +ultime sono separate dal contenuto del file diventa necessario l'utilizzo di +un altro tempo. Si noti inoltre come \var{st\_ctime} non abbia nulla a che +fare con il tempo di creazione usato da molti altri sistemi operativi, che in +unix non esiste. + + + + \subsection{La funzione \texttt{utime}} \label{sec:filedir_utime} diff --git a/fileintro.tex b/fileintro.tex index d1c8e13..d0ca221 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -339,7 +339,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \begin{figure}[htb] \centering - + \includegraphics[width=5cm]{img/vfs.eps} \caption{Schema delle operazioni del VFS} \label{fig:fileintro_VFS_scheme} \end{figure} diff --git a/gapil.tex b/gapil.tex index 2564ee7..5e1fc77 100644 --- a/gapil.tex +++ b/gapil.tex @@ -1,4 +1,4 @@ -%% +%% %% GaPiL : Guida alla Programmazione in Linux %% %% S. Piccardi Feb. 2001 @@ -62,7 +62,6 @@ \end{quote} \clearemptydoublepage - \tableofcontents \clearemptydoublepage diff --git a/img/link_loop.dia b/img/link_loop.dia new file mode 100644 index 0000000000000000000000000000000000000000..179491c9d3d4829f46b569be9b9fcb0b45e27bb4 GIT binary patch literal 1655 zcmV--28j6|iwFP!000001MOT}bE7sCe$TJ)u&=Bv35m;Qlbvp-Z=Gppw(lMsD>f|# z56DTJhyM18OV$Pin2WM@7iZ!bgM2=Y^l`p(#7RDXdD;52Cl5%9e|h}ryK*Z1AI7&O=JZ)USo11p!i z$+7&X%X#E2_ngfFcgyayrTg&DItur}O3Oy&;~qjkjAl=+f2VzTOkdhOH#0BTX|TO> zcPuKK-R{EJ6GQl6R~b@cCwV^^laGqUpkRIf;TQ5DyQKWU(U$B&YeD$djn-aJ#fg~f zXA^;ejWK?khwczd^$@;#h)6wz7cX{U#3R?^RhVTM`pgY7Bp&Tqf1LQi^#x^`TtWS< zKYE;pE!Y3(`tdmqWQV`sJzej_b>yv@Z^Xig8Y|DK0~Tkg?3b`9Vo+t8cH#Hs zv;d?KQXK<`9m6coKy_*BV3x}=N+jHIgSF2xBojCkQ>sHiOo!Ye1Wd!AIsph`==1|# zve!lGOfMI!LmeGAokkEqi|R;tVk6Q#QYZafdI+O{MT>+66{lFR-)8n<1zdWr3$V}- zwut$`XZ5hSpXrqwZ+sT4`KHQ|x2On#(a(6y-H0#TC<>oPzwi^=i*^U>;UKAejDYbF z27$Q!M68HQ#*SxZ8xdoYNF;&@4@EF>wAu0OomM5dUHO?*gbr2_sEe?!QbjC4ED=e}TthIRm?W6jAt6s&Q5ElB zKLRkxNKY9lGi;KPQ6fS^Ic$y)6&!^j!AYwTp&?1_D{>4`oD!AgZ_yn&MN#8`q^1Fm zMHSY*<@&W#@rxDLz71rvu59nc#u*Z_v%ME&Dd%6O?H6P<@4pBoRZGMnn=s_Z@zB05 z9@-Yl_5h)i@sM899w2Sz;HA>9ya(Nzf624DUBQ>yhjZbJgp5wxbIB?lC90FJ7?P}5 zr>D9VQr7JEfFyrPp3ga!z!S7YFlUT42wz_DDRfv`0#=gWp#YKuyWBuBpr>OKJ})F) zO@sPJs%-C9b|N?izsdK+Gt1IGXwuTOy*TXyRV`3E5wRbrtXw^_VC@4}SG2a3tz5-lW^5Mz&j;WO!yF!&4=qgFKsrvs;_0tYfCB^`t9+v~Q-l zb4I=R<1uc)bPtFEto$ytfo(&glXU+XCtYVysJ?(sHlXn&`ai4a%Lq8B{l%%hF^<|> z@1yqSQSF^~QhRGs`-?4;$w*2mUP+T6rthGZqDD5TZUGa$$)zde(gp-wnOv@;{c@7a z5#>_K!bvj6mdx&bLx_&ifNCgjKuzD%4pgeT1J#&%hg#Li9HRx5sBJ-|09n`;>zTI? znZU*tPGGO2e+W#CLqqyc$<#RXo{dAux~k40auJ%7Wpw z^`GWQ7-fBbf-o1=e~MvC|EY7q{ih)F0020b BLpuNf literal 0 HcmV?d00001 diff --git a/img/vfs.dia b/img/vfs.dia new file mode 100644 index 0000000000000000000000000000000000000000..14c1f1bdf1fa0428366b7521f4d8f68a38f221a3 GIT binary patch literal 2798 zcmVR2R1O3J93k{$9EOXyF)t!AFCsNBBFwJ$Nt&mAm^a1TBuNzbaVaTJ z?}PDjvb7&clR2ge9N+tGnCHof`@i+0td9ca*U#t~io|UiZjJ--phZV7kKrc2yZ&xy zxXRw24E6pHX5mc~wB3Ce=aY5+q}jdhbG{EZL3ZLvAGYb}>8@&aaZ2%eyS^HfU)4ye z5E1!LL0WbH`GuYq)fiWxe>Dop&3}V+Ua9vr_v4M9ZWf;wpOf#)7jku%i*R$f{Fi$; zJavU+XVUpJ#%G^AKS$T0b#czgWjsji5V z!_!lOvLtD+5?EQSvzOm2?j#gds40<`ClYyhxp?{Q<N!2)A%8P4)lP=bf@75+C2d*u;|JEr4uM&sUftTYfY%v%DN4U!$4??XpnDn#tQ`1 zSl{SmNsYCXre&Y7aK?}lP2}Zx>A4!5 zhV1&Bz0s=cffq}lwU)K@(!1NNW5M+3-FGi@C2`&^QT?WB^d-4ZLy6l9U1=?lITetN z6;-#r-u5?6T(RQbF7WkYyj%R!7w1ReHr@qY&+a8QfCFT;F8&PiCFM7-XmU)POm*XA z287^H!dv=y&dtWkRL01KAcEjZ#;pX4!p+FRdPa@g8@Eizo!=9r{ z&6bw9S_QDq!#a=t&V%SU5B4_BgKIkvqsQI{~ zQ_q&B+|E0!^BCwnsE+dxZ{s|K_N2x5&YqmCNEs^*)b`nEQT=Bpr}y!=-N&<@VSs0- zPb<8czzwyt&fqM2_mY^Y>q3R{Vm={5{5g;g`|a98Y~gO;LM-shxRpkHGAc$NAj#zShd?nDj|!@_*}`e9n$6xrn+33-rA!DXtv0s+K{ z$>@~;>=kQJ9(D0b<>c`~ERmPv#MUzG`eotu&%ry$!228}>u-xq@DQ$p#m)WgZICY3 z{`xNH%*#8La@8{@uUAIiP&uvHc&Bplh6-us;q|qQ)Q-eo0e`oEnS;1*(Bv$^VM^`D(Hf9R&?2tuJ^&4d=h(}uc%8J z77^5YCQnF!=MwTB*)t8oEJ!VXPQ{S;% z`Ev&TMD8TET!j8;4nuyKdP2pXujZcceX-}mt)E-&oQykLEYLEidFDL$W)zzuczT1Q z%?GvA79Z^Ck69pZ@j{&|V3OZpv2#g)t8yKxPrV!HB3Kj3cJONh!%|m1iC%rSZr}vM zjuCDj%00Q|aY(x(57t7HnSEzTy+Hs-q2z~9%!@+=ic19o?d`CRWS^nRn;oip9#AtE zhzt|ZnwO$k^WHN*1sy3~>C91?7!P08vRr1Qu2G#kD%>QTHweLE@Cn_aCe491bY+ zydtfMK}w`xtgg?$nBePEmIu4V7e9&?f5dr^-ui1>NT63p(6BmNNMQ7}7GjbjTBI^| z#@4I#E1Gu;Aub~;^*#$aQweQDv95OZkStq7+rMNUYZTF9_f3juvGy@K<5AMHFi{oJ zk|N+O(ykCQ9Po};s8_@bZN%Fv;>B>P;#m(MiiFWq+z`WD(U%7~Rm+}?c}NK+^7{NE z-rvi@+27Of;Yh->jdXjJ%+{^VM!E)HkBE`}`w?e&J!1LspI@gMYZnRQ*Dg9*F=wBBHzz?@qQA^#}O?GEWk&g!%{yKrQZznK2vq1gE0q4+g}nWnJu3iaYJ zWI3!Khw%yCwMmpm!3dbm^FdG%7=~3|D*_&u1SZ8E=Cz*fwnvzKTYQnMk|t4PH$KJ^ zSi8Ad_L}viP(00{Ey$VWh$ywC|D(8^I^H~owrJ_r@3a zWSX;DYAeEKOjx>ACa^=R@C+iCIUKmmWf~{y?d8y1x0E-XQn954J=p>~{OnE1%=uOX zPI9QSb2wKsVrR7QlvHL9ZZbhhp#LzBmXH#uRfF)@@Jd+yQ>fX2b!>GcqE?y04;iz AkN^Mx literal 0 HcmV?d00001 diff --git a/intro.tex b/intro.tex index 6fc0fec..cc6dcfa 100644 --- a/intro.tex +++ b/intro.tex @@ -229,18 +229,75 @@ descritti in precedenza sono disattivati. \section{Gli standard di unix e GNU/Linux} \label{sec:intro_standard} - +In questa sezione prenderemo in esame alcune caratteristiche generali del +sistema e gli standard adottati per le funzioni, i prototipi, gli errori, i +tipi di dati. + +\subsection{Prototipi e puntatori} +\label{sec:intro_function} + +\subsection{La misura del tempo in unix} +\label{sec:intro_unix_time} + +Storicamente i sistemi unix-like hanno sempre mantenuto due distinti valori +per i tempi all'interno del sistema, chiamati rispettivamente \textit{calendar + time} e \textit{process time}, secondo le definizioni: +\begin{itemize} +\item \textit{calendar time}: è il numero di secondi dalla mezzanotte del + primo gennaio 1970, in tempo universale coordinato (o UTC, data che viene + usualmente indicata con 00:00:00 Jan, 1 1970 (UTC) e chiamata \textit{the + Epoch}). Viene chiamato anche GMT (Greenwich Mean Time) dato che l'UTC + corrisponde all'ora locale di Greenwich. E' il tempo su cui viene mantenuto + l'orologio del calcolatore, e viene usato ad esempio per indicare le date di + modifica dei file o quelle di avvio dei processi. Per memorizzare questo + tempo è stato riservato il tipo primitivo \func{time\_t}. +\item \textit{process time}: talvolta anche detto tempo di CPU. Viene misurato + in \textit{clock tick}, corripondenti al numero di interruzioni effettuate + dal timer di sistema, e che per Linux sono ogni centesimo di secondo + (eccetto per la piattaforma alpha). Il dato primitivo usato per questo tempo + è \func{clock\_t}, inoltre la costante \macro{HZ} restituisce la frequenza + di operazione del timer, e corrisponde dunque al numero di tick al secondo + (Posix definisce allo stesso modo la costante \macro{CLK_TCK}); questo + valore può comunque essere ottenuto con \func{sysconf} (vedi + \secref{sec:intro_limits}). +\end{itemize} + +In genere si usa il \textit{calendar time} per tenere le date dei file e le +informazioni analoghe che riguardano i tempi di ``orologio'' (usati ad esempio +per i demoni che compiono lavori amministrativi ad ore definite, come +\cmd{cron}). Di solito questo vene convertito automaticamente dal valore in +UTC al tempo locale, utilizzando le opportune informazioni di localizzazione +(specificate in \file{/etc/timezone}). E da tenere presente che questo tempo è +mantenuto dal sistema e non corrisponde all'orologio hardware del calcolatore. + +Il \textit{process time} di solito si esprime in secondi e viene usato appunto +per tenere conto dei tempi di esecuzione dei processi. Per ciascun processo il +kernel tiene tre di questi tempi: +\begin{itemize} +\item \textit{clock time} +\item \textit{user time} +\item \textit{system time} +\end{itemize} +il primo è il tempo ``reale'' (viene anche chiamato \textit{wall clock time}) +dall'avvio del processo, e misura il tempo trascorso fino alla sua +conclusione; chiaramente un tale tempo dipede anche dal carico del sistema e +da quanti altri processi stavano girando nello stesso periodo. Il secondo +tempo è quello che la CPU ha speso nell'esecuzione delle istruzioni del +processo in user space. Il terzo è il tempo impiegato dal kernel per eseguire +delle system call per conto del processo medesimo (tipo quello usato per +eseguire una \func{write} su un file). In genere la somma di user e system +time viene chiamato \textit{CPU time}. \subsection{Lo standard ANSI C} \label{sec:intro_ansiC} - - \subsection{Lo standard POSIX} \label{sec:intro_posix} +\subsection{Valori e limiti del sistema} +\label{sec:intro_limits} - - +\subsection{Tipi di dati primitivi} +\label{sec:intro_data_types} -- 2.30.2