Il tipo di filesystem che si vuole montare è specificato
dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
-riportate nel file \procfile{/proc/filesystems} che, come accennato in
+riportate nel file \procfilem{/proc/filesystems} che, come accennato in
sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
\label{fig:sys_statfs}
\end{figure}
-\conffilebeg{/etc/mtab}
+\conffilebeg{/etc/mtab}
+
La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
\funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
\funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
filesystem da montare e a quelli correntemente montati. Le funzioni servono a
-leggere il contenuto di questi file in opportune strutture \struct{fstab} e
-\struct{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e rimuovere
-le voci presenti nel file.
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
+rimuovere le voci presenti nel file.
In generale si dovrebbero usare queste funzioni, in particolare quelle
relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
disponibile e sempre aggiornata. Per questo motivo tralasceremo la
trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
\cite{GlibcMan} per la documentazione completa.
+
\conffileend{/etc/mtab}
% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
necessità di specificare il numero tramite delle opportune macro, così da non
avere problemi di compatibilità con eventuali ulteriori estensioni.
-Le macro sono definite nel file \headfile{sys/sysmacros.h},\footnote{se si usa
- la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
+Le macro sono definite nel file \headfiled{sys/sysmacros.h},\footnote{se si
+ usa la \acr{glibc} dalla versione 2.3.3 queste macro sono degli alias alle
versioni specifiche di questa libreria, \macrod{gnu\_dev\_major},
\macrod{gnu\_dev\_minor} e \macrod{gnu\_dev\_makedev} che si possono usare
direttamente, al costo di una minore portabilità.} che viene automaticamente
tramite il suo file descriptor \param{filedes}.
La struttura \struct{stat} usata da queste funzioni è definita nell'header
-\headfile{sys/stat.h} e in generale dipende dall'implementazione; la versione
+\headfiled{sys/stat.h} e in generale dipende dall'implementazione; la versione
usata da Linux è mostrata in fig.~\ref{fig:file_stat_struct}, così come
riportata dalla pagina di manuale di \func{stat}. In realtà la definizione
effettivamente usata nel kernel dipende dall'architettura e ha altri campi
\textit{inheritable} ed \textit{effective}. Questi insiemi vengono mantenuti
in forma di tre diverse maschere binarie,\footnote{il kernel li mantiene, come
i vari identificatori di sez.~\ref{sec:proc_setuid}, all'interno della
- \struct{task\_struct} di ciascun processo (vedi
+ \texttt{task\_struct} di ciascun processo (vedi
fig.~\ref{fig:proc_task_struct}), nei tre campi \texttt{cap\_effective},
\texttt{cap\_inheritable}, \texttt{cap\_permitted} del tipo
\texttt{kernel\_cap\_t}; questo era, fino al kernel 2.6.25 definito come
Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
è diventato una proprietà di ciascun processo, che viene propagata invariata
sia attraverso una \func{fork} che una \func{exec}. In questo caso il file
-\sysctlfile{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
+\sysctlfilem{kernel/cap-bound} non esiste e \texttt{init} non ha nessun
ruolo speciale, inoltre in questo caso all'avvio il valore iniziale prevede la
presenza di tutte le capacità (compresa \const{CAP\_SETPCAP}).
indicato che per poterle utilizzare fosse necessario che la macro
\macro{\_POSIX\_SOURCE} risultasse non definita (ed era richiesto di inserire
una istruzione \texttt{\#undef \_POSIX\_SOURCE} prima di includere
-\headfile{sys/capability.h}) requisito che non risulta più
+\headfiled{sys/capability.h}) requisito che non risulta più
presente.\footnote{e non è chiaro neanche quanto sia mai stato davvero
necessario.}
\centering
\begin{minipage}[c]{0.8\textwidth}
\includestruct{listati/cap_user_header_t.h}
- \end{minipage}
+ \end{minipage}
\normalsize
\caption{Definizione delle strutture a cui fanno riferimento i puntatori
\structd{cap\_user\_header\_t} e \structd{cap\_user\_data\_t} usati per
projects / gapil.git / blobdiff