% http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
% TODO completare la parte su quando viene chiamato lo scheduler.
-Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
-\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito in occasione di dell'invocazione di ogni \textit{system call} ed per
-ogni interrupt dall'hardware oltre che in una serie di altre occasioni, e può
-essere anche attivato esplicitamente. Il timer di sistema provvede comunque a
-che esso sia invocato periodicamente, generando un interrupt periodico secondo
-una frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
-(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
-che lo \textit{scheduler} scheduler venga comunque eseguito ad intervalli
-regolari e possa prendere le sue decisioni.
+\itindbeg{scheduler}
+Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \textit{scheduler} che
+decide quale processo mettere in esecuzione; esso viene eseguito in occasione
+di dell'invocazione di ogni \textit{system call} ed per ogni interrupt
+dall'hardware oltre che in una serie di altre occasioni, e può essere anche
+attivato esplicitamente. Il timer di sistema provvede comunque a che esso sia
+invocato periodicamente, generando un interrupt periodico secondo una
+frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
+(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
+che lo \textit{scheduler} venga comunque eseguito ad intervalli regolari e
+possa prendere le sue decisioni.
A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
completamente diverso, detto \textit{tickless}, in cui non c'è più una
sospensione anche per lunghi periodi di tempo.
Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
-viene eseguito lo \itindex{scheduler} \textit{scheduler} effettua il calcolo
-delle priorità dei vari processi attivi (torneremo su questo in
-sez.~\ref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
-esecuzione fino alla successiva invocazione.
+viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
+vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
+stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
+invocazione.
+\itindend{scheduler}
\subsection{Gli identificatori dei processi}
\label{sec:proc_pid}
e poi il padre.
In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
-\itindex{scheduler} \textit{scheduling} usato dal kernel, dalla particolare
-situazione in cui si trova la macchina al momento della chiamata, risultando
-del tutto impredicibile. Eseguendo più volte il programma di prova e
-producendo un numero diverso di figli, si sono ottenute situazioni
-completamente diverse, compreso il caso in cui il processo padre ha eseguito
-più di una \func{fork} prima che uno dei figli venisse messo in esecuzione.
+\textit{scheduling} usato dal kernel, dalla particolare situazione in cui si
+trova la macchina al momento della chiamata, risultando del tutto
+impredicibile. Eseguendo più volte il programma di prova e producendo un
+numero diverso di figli, si sono ottenute situazioni completamente diverse,
+compreso il caso in cui il processo padre ha eseguito più di una \func{fork}
+prima che uno dei figli venisse messo in esecuzione.
Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
-\textit{scheduler} è stato modificato per eseguire sempre per primo il
-figlio.\footnote{i risultati precedenti infatti sono stati ottenuti usando un
- kernel della serie 2.4.} Questa è una ottimizzazione adottata per evitare
-che il padre, effettuando per primo una operazione di scrittura in memoria,
-attivasse il meccanismo del \itindex{copy~on~write} \textit{copy on write},
-operazione inutile qualora il figlio venga creato solo per eseguire una
-\func{exec} su altro programma che scarta completamente lo spazio degli
-indirizzi e rende superflua la copia della memoria modificata dal
-padre. Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata
-subito, con la certezza di utilizzare \itindex{copy~on~write} \textit{copy on
- write} solo quando necessario.
+In realtà con l'introduzione dei kernel della serie 2.6 lo \textit{scheduler}
+è stato modificato per eseguire sempre per primo il figlio.\footnote{i
+ risultati precedenti infatti sono stati ottenuti usando un kernel della
+ serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre,
+effettuando per primo una operazione di scrittura in memoria, attivasse il
+meccanismo del \itindex{copy~on~write} \textit{copy on write}, operazione
+inutile qualora il figlio venga creato solo per eseguire una \func{exec} su
+altro programma che scarta completamente lo spazio degli indirizzi e rende
+superflua la copia della memoria modificata dal padre. Eseguendo sempre per
+primo il figlio la \func{exec} verrebbe effettuata subito, con la certezza di
+utilizzare \itindex{copy~on~write} \textit{copy on write} solo quando
+necessario.
Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
proprietà; la lista dettagliata delle proprietà che padre e figlio hanno in
comune dopo l'esecuzione di una \func{fork} è la seguente:
\begin{itemize*}
-\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
- \textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
- sez.~\ref{sec:file_fcntl_ioctl});
+\item i file aperti e gli eventuali flag di \textit{close-on-exec} impostati
+ (vedi sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl_ioctl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
(vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
-\item la \index{maschera~dei~segnali} maschera dei segnali bloccati (vedi
+\item la maschera dei segnali bloccati (vedi
sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
% TODO ===========Importante=============
% TODO questo sotto è incerto, verificare
% TODO ===========Importante=============
-\item la \index{maschera~dei~segnali} maschera dei segnali (si veda
- sez.~\ref{sec:sig_sigmask}).
+\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
\end{itemize*}
Una serie di proprietà del processo originale, che non avrebbe senso mantenere
\begin{itemize*}
\item le operazioni di I/O asincrono (vedi sez.~\ref{sec:file_asyncronous_io})
pendenti vengono cancellate;
-\item le \itindex{capabilities} \textit{capabilities} vengono modificate come
+\item le \textit{capabilities} vengono modificate come
illustrato in sez.~\ref{sec:proc_capabilities};
-\item tutti i \itindex{thread} \textit{thread} tranne il chiamante (vedi
+\item tutti i \textit{thread} tranne il chiamante (vedi
sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
\item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
localizzazione al valore di default POSIX.
\end{itemize*}
+\itindbeg{close-on-exec}
+
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
-\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
-\textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
-altri file restano aperti. Questo significa che il comportamento predefinito è
-che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
-esplicita a \func{fcntl} che imposti il suddetto flag. Per le directory, lo
-standard POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec},
-in genere questo è fatto dalla funzione \func{opendir} (vedi
+\func{exec} dipende dal valore che ha il flag di \textit{close-on-exec} (vedi
+sez.~\ref{sec:file_fcntl_ioctl}) per ciascun \textit{file descriptor}. I file
+per cui è impostato vengono chiusi, tutti gli altri file restano
+aperti. Questo significa che il comportamento predefinito è che i file restano
+aperti attraverso una \func{exec}, a meno di una chiamata esplicita a
+\func{fcntl} che imposti il suddetto flag. Per le directory, lo standard
+POSIX.1 richiede che esse vengano chiuse attraverso una \func{exec}, in genere
+questo è fatto dalla funzione \func{opendir} (vedi
sez.~\ref{sec:file_dir_read}) che effettua da sola l'impostazione del flag di
-\itindex{close-on-exec} \textit{close-on-exec} sulle directory che apre, in
-maniera trasparente all'utente.
+\textit{close-on-exec} sulle directory che apre, in maniera trasparente
+all'utente.
+
+\itindend{close-on-exec}
+
Il comportamento della funzione in relazione agli identificatori relativi al
controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
Come accennato in sez.~\ref{sec:intro_multiuser} il modello base\footnote{in
realtà già esistono estensioni di questo modello base, che lo rendono più
- flessibile e controllabile, come le \itindex{capabilities}
- \textit{capabilities} illustrate in sez.~\ref{sec:proc_capabilities}, le ACL
- per i file (vedi sez.~\ref{sec:file_ACL}) o il
- \itindex{Mandatory~Access~Control~(MAC)} \textit{Mandatory Access Control}
- di \index{SELinux} SELinux; inoltre basandosi sul lavoro effettuato con
- SELinux, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
- infrastruttura di sicurezza, i \itindex{Linux~Security~Modules}
- \textit{Linux Security Modules}, o LSM, in grado di fornire diversi agganci
- a livello del kernel per modularizzare tutti i possibili controlli di
- accesso, cosa che ha permesso di realizzare diverse alternative a
- \index{SELinux} SELinux.} di sicurezza di un sistema unix-like è fondato sui
-concetti di utente e gruppo, e sulla separazione fra l'amministratore
-(\textsl{root}, detto spesso anche \textit{superuser}) che non è sottoposto a
-restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i
-vari controlli di accesso.
+ flessibile e controllabile, come le \textit{capabilities} illustrate in
+ sez.~\ref{sec:proc_capabilities}, le ACL per i file (vedi
+ sez.~\ref{sec:file_ACL}) o il \textit{Mandatory Access Control} di
+ \textit{SELinux}; inoltre basandosi sul lavoro effettuato con
+ \textit{SELinux}, a partire dal kernel 2.5.x, è iniziato lo sviluppo di una
+ infrastruttura di sicurezza, i \textit{Linux Security Modules}, o LSM, in
+ grado di fornire diversi agganci a livello del kernel per modularizzare
+ tutti i possibili controlli di accesso, cosa che ha permesso di realizzare
+ diverse alternative a \textit{SELinux}.}
+di sicurezza di un sistema unix-like è fondato sui concetti di utente e
+gruppo, e sulla separazione fra l'amministratore (\textsl{root}, detto spesso
+anche \textit{superuser}) che non è sottoposto a restrizioni, ed il resto
+degli utenti, per i quali invece vengono effettuati i vari controlli di
+accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
Infine per impostare i gruppi supplementari di un processo ci sono due
funzioni, che possono essere usate solo se si hanno i privilegi di
-amministratore.\footnote{e più precisamente se si ha la \itindex{capabilities}
- \textit{capability} \macro{CAP\_SETGID}.} La prima delle due è la funzione
-di sistema \funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4,
- ma a differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
+amministratore.\footnote{e più precisamente se si ha la \textit{capability}
+ \macro{CAP\_SETGID}.} La prima delle due è la funzione di sistema
+\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
+ differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
il suo prototipo è:
\label{sec:proc_priority}
In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \itindex{scheduler} \textit{scheduler} assegna la CPU ai vari processi
-attivi. In particolare prenderemo in esame i vari meccanismi con cui viene
-gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
-gestione. Tratteremo infine anche le altre priorità dei processi (come quelle
-per l'accesso a disco) divenute disponibili con i kernel più recenti.
+lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
+prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
+tempo di CPU, ed illustreremo le varie funzioni di gestione. Tratteremo infine
+anche le altre priorità dei processi (come quelle per l'accesso a disco)
+divenute disponibili con i kernel più recenti.
\subsection{I meccanismi di \textit{scheduling}}
Il meccanismo usato da Linux è in realtà piuttosto complesso,\footnote{e
dipende strettamente dalla versione di kernel; in particolare a partire
- dalla serie 2.6.x lo scheduler è stato riscritto completamente, con molte
- modifiche susseguitesi per migliorarne le prestazioni, per un certo periodo
- ed è stata anche introdotta la possibilità di usare diversi algoritmi,
- selezionabili sia in fase di compilazione, che, nelle versioni più recenti,
- all'avvio (addirittura è stato ideato un sistema modulare che permette di
- cambiare lo scheduler a sistema attivo).} ma a grandi linee si può dire che
-ad ogni processo è assegnata una \textit{time-slice}, cioè un intervallo di
-tempo (letteralmente una fetta) per il quale, a meno di eventi esterni, esso
-viene eseguito senza essere interrotto. Inoltre la priorità dinamica viene
-calcolata dallo scheduler a partire da un valore iniziale che viene
-\textsl{diminuito} tutte le volte che un processo è in stato \textit{runnable}
-ma non viene posto in esecuzione.\footnote{in realtà il calcolo della priorità
- dinamica e la conseguente scelta di quale processo mettere in esecuzione
- avviene con un algoritmo molto più complicato, che tiene conto anche della
- \textsl{interattività} del processo, utilizzando diversi fattori, questa è
- una brutale semplificazione per rendere l'idea del funzionamento, per una
- trattazione più dettagliata, anche se non aggiornatissima, dei meccanismi di
- funzionamento dello scheduler si legga il quarto capitolo di
- \cite{LinKernDev}.} Lo scheduler infatti mette sempre in esecuzione, fra
-tutti i processi in stato \textit{runnable}, quello che ha il valore di
-priorità dinamica più basso.\footnote{con le priorità dinamiche il significato
- del valore numerico ad esse associato è infatti invertito, un valore più
- basso significa una priorità maggiore.} Il fatto che questo valore venga
-diminuito quando un processo non viene posto in esecuzione pur essendo pronto,
-significa che la priorità dei processi che non ottengono l'uso del processore
-viene progressivamente incrementata, così che anche questi alla fine hanno la
+ dalla serie 2.6.x lo \textit{scheduler} è stato riscritto completamente, con
+ molte modifiche susseguitesi per migliorarne le prestazioni, per un certo
+ periodo ed è stata anche introdotta la possibilità di usare diversi
+ algoritmi, selezionabili sia in fase di compilazione, che, nelle versioni
+ più recenti, all'avvio (addirittura è stato ideato un sistema modulare che
+ permette di cambiare lo \textit{scheduler} a sistema attivo).} ma a grandi
+linee si può dire che ad ogni processo è assegnata una \textit{time-slice},
+cioè un intervallo di tempo (letteralmente una fetta) per il quale, a meno di
+eventi esterni, esso viene eseguito senza essere interrotto. Inoltre la
+priorità dinamica viene calcolata dallo \textit{scheduler} a partire da un
+valore iniziale che viene \textsl{diminuito} tutte le volte che un processo è
+in stato \textit{runnable} ma non viene posto in esecuzione.\footnote{in
+ realtà il calcolo della priorità dinamica e la conseguente scelta di quale
+ processo mettere in esecuzione avviene con un algoritmo molto più
+ complicato, che tiene conto anche della \textsl{interattività} del processo,
+ utilizzando diversi fattori, questa è una brutale semplificazione per
+ rendere l'idea del funzionamento, per una trattazione più dettagliata, anche
+ se non aggiornatissima, dei meccanismi di funzionamento dello
+ \textit{scheduler} si legga il quarto capitolo di \cite{LinKernDev}.} Lo
+\textit{scheduler} infatti mette sempre in esecuzione, fra tutti i processi in
+stato \textit{runnable}, quello che ha il valore di priorità dinamica più
+basso.\footnote{con le priorità dinamiche il significato del valore numerico
+ ad esse associato è infatti invertito, un valore più basso significa una
+ priorità maggiore.} Il fatto che questo valore venga diminuito quando un
+processo non viene posto in esecuzione pur essendo pronto, significa che la
+priorità dei processi che non ottengono l'uso del processore viene
+progressivamente incrementata, così che anche questi alla fine hanno la
possibilità di essere eseguiti.
Sia la dimensione della \textit{time-slice} che il valore di partenza della
che ciascun processo si porta dietro, essa viene ereditata dai processi
figli e mantenuta attraverso una \func{exec}; fino alla serie 2.4 essa era
mantenuta nell'omonimo campo \texttt{nice} della \texttt{task\_struct}, con
- la riscrittura dello scheduler eseguita nel 2.6 viene mantenuta nel campo
- \texttt{static\_prio} come per le priorità statiche.} L'origine del nome di
-questo parametro sta nel fatto che generalmente questo viene usato per
+ la riscrittura dello \textit{scheduler} eseguita nel 2.6 viene mantenuta nel
+ campo \texttt{static\_prio} come per le priorità statiche.} L'origine del
+nome di questo parametro sta nel fatto che generalmente questo viene usato per
\textsl{diminuire} la priorità di un processo, come misura di cortesia nei
confronti degli altri. I processi infatti vengono creati dal sistema con un
valore nullo e nessuno è privilegiato rispetto agli altri. Specificando un
il risultato nell'intervallo consentito. Valori positivi comportano maggiore
\textit{cortesia} e cioè una diminuzione della priorità, valori negativi
comportano invece un aumento della priorità. Con i kernel precedenti il 2.6.12
-solo l'amministratore\footnote{o un processo con la \itindex{capabilities}
- \textit{capability} \const{CAP\_SYS\_NICE}, vedi
- sez.~\ref{sec:proc_capabilities}.} può specificare valori negativi
-di \param{inc} che permettono di aumentare la priorità di un processo, a
-partire da questa versione è consentito anche agli utenti normali alzare
-(entro certi limiti, che vedremo in sez.~\ref{sec:sys_resource_limit}) la
-priorità dei propri processi.
+solo l'amministratore\footnote{o un processo con la \textit{capability}
+ \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} può
+specificare valori negativi di \param{inc} che permettono di aumentare la
+priorità di un processo, a partire da questa versione è consentito anche agli
+utenti normali alzare (entro certi limiti, che vedremo in
+sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
\textit{nice} valido.
Si tenga presente che solo l'amministratore\footnote{o più precisamente un
- processo con la \itindex{capabilities} \textit{capability}
- \const{CAP\_SYS\_NICE}, vedi sez.~\ref{sec:proc_capabilities}.} ha la
-possibilità di modificare arbitrariamente le priorità di qualunque
-processo. Un utente normale infatti può modificare solo la priorità dei suoi
-processi ed in genere soltanto diminuirla. Fino alla versione di kernel
-2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i
-sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello
-effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo
-a quello) del processo di cui si intendeva cambiare la priorità. A partire
-dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi
-derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere
-anche con l'\ids{UID} effettivo.
+ processo con la \textit{capability} \const{CAP\_SYS\_NICE}, vedi
+ sez.~\ref{sec:proc_capabilities}.} ha la possibilità di modificare
+arbitrariamente le priorità di qualunque processo. Un utente normale infatti
+può modificare solo la priorità dei suoi processi ed in genere soltanto
+diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le
+specifiche dello standard SUSv3, e come per tutti i sistemi derivati da SysV
+veniva richiesto che l'\ids{UID} reale o quello effettivo del processo
+chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo
+di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è
+stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS,
+Ultrix, *BSD), in cui la corrispondenza può essere anche con l'\ids{UID}
+effettivo.
Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti
ordinari poter aumentare la priorità dei propri processi specificando un
La politica \const{SCHED\_BATCH} è una variante della politica ordinaria con
la sola differenza che i processi ad essa soggetti non ottengono, nel calcolo
-delle priorità dinamiche fatto dallo scheduler, il cosiddetto bonus di
-interattività che mira a favorire i processi che si svegliano dallo stato di
-\textit{sleep}.\footnote{cosa che accade con grande frequenza per i processi
- interattivi, dato che essi sono per la maggior parte del tempo in attesa di
- dati in ingresso da parte dell'utente.} La si usa pertanto, come indica il
-nome, per processi che usano molta CPU (come programmi di calcolo) che in
-questo modo sono leggermente sfavoriti rispetto ai processi interattivi che
-devono rispondere a dei dati in ingresso, pur non perdendo il loro valore di
-\textit{nice}.
+delle priorità dinamiche fatto dallo \textit{scheduler}, il cosiddetto bonus
+di interattività che mira a favorire i processi che si svegliano dallo stato
+di \textit{sleep}.\footnote{cosa che accade con grande frequenza per i
+ processi interattivi, dato che essi sono per la maggior parte del tempo in
+ attesa di dati in ingresso da parte dell'utente.} La si usa pertanto, come
+indica il nome, per processi che usano molta CPU (come programmi di calcolo)
+che in questo modo sono leggermente sfavoriti rispetto ai processi interattivi
+che devono rispondere a dei dati in ingresso, pur non perdendo il loro valore
+di \textit{nice}.
La politica \const{SCHED\_IDLE} invece è una politica dedicata ai processi che
si desidera siano eseguiti con la più bassa priorità possibile, ancora più
nel caso che esso sia stato interrotto da un processo a priorità più alta.
Solo un processo con i privilegi di amministratore\footnote{più precisamente
- con la \itindex{capabilities} capacità \const{CAP\_SYS\_NICE}, vedi
+ con la capacità \const{CAP\_SYS\_NICE}, vedi
sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità
assolute diverse da zero o politiche \const{SCHED\_FIFO} e
\const{SCHED\_RR}. Un utente normale può modificare solo le priorità di
processore.
Nell'uso comune, almeno con i kernel successivi alla serie 2.6.x, l'uso di
-questa funzione non è necessario, in quanto è lo scheduler stesso che provvede
-a mantenere al meglio l'affinità di processore. Esistono però esigenze
-particolari, ad esempio quando un processo (o un gruppo di processi) è
-utilizzato per un compito importante (ad esempio per applicazioni
+questa funzione non è necessario, in quanto è lo \textit{scheduler} stesso che
+provvede a mantenere al meglio l'affinità di processore. Esistono però
+esigenze particolari, ad esempio quando un processo (o un gruppo di processi)
+è utilizzato per un compito importante (ad esempio per applicazioni
\textit{real-time} o la cui risposta è critica) e si vuole la massima
velocità, e con questa interfaccia diventa possibile selezionare gruppi di
processori utilizzabili in maniera esclusiva. Lo stesso dicasi quando
utilizzate anche in un sistema con un processore singolo, nel qual caso però
non avranno alcun risultato effettivo.
-
\itindend{scheduler}
\itindend{CPU~affinity}
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
- \itindex{capabilities} \textit{capabilities} (vedi
- sez.~\ref{sec:proc_capabilities}). La funzione ritorna 1 se la capacità
- specificata nell'argomento \param{arg2} (con una delle costanti di
- tab.~\ref{tab:proc_capabilities}) è presente nel \textit{capabilities
- bounding set} del processo e zero altrimenti, se \param{arg2} non è un
- valore valido si avrà un errore di \errval{EINVAL}. Introdotta a partire
- dal kernel 2.6.25.
+ \textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
+ ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
+ delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
+ \textit{capabilities bounding set} del processo e zero altrimenti,
+ se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
+ Introdotta a partire dal kernel 2.6.25.
\item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
- \itindex{capabilities} \textit{capabilities} (vedi
- sez.~\ref{sec:proc_capabilities}) dal processo e da tutti i suoi
- discendenti. La funzione cancella la capacità specificata
+ \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
+ da tutti i suoi discendenti. La funzione cancella la capacità specificata
nell'argomento \param{arg2} con una delle costanti di
- tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set}
- \itindex{capabilities~bounding~set} del processo. L'operazione richiede i
- privilegi di amministratore (la capacità \const{CAP\_SETPCAP}), altrimenti
- la chiamata fallirà con un errore di \errcode{EPERM}; se il valore
- di \param{arg2} non è valido o se il supporto per le \textit{file
- capabilities} non è stato compilato nel kernel la chiamata fallirà con un
- errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25.
+ tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
+ processo. L'operazione richiede i privilegi di amministratore (la capacità
+ \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
+ \errcode{EPERM}; se il valore di \param{arg2} non è valido o se il supporto
+ per le \textit{file capabilities} non è stato compilato nel kernel la
+ chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
+ kernel 2.6.25.
\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
terminazione di un processo a causa di un segnale per il quale è prevista la
a partire dal kernel 2.4.21, solo su PowerPC.
\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
- \itindex{capabilities} \textit{capabilities} vengono cancellate quando si
- esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda
+ \textit{capabilities} vengono cancellate quando si esegue un cambiamento di
+ \ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default)
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
dal kernel 2.2.18.
\item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
- il valore del flag di controllo delle \itindex{capabilities}
- \textit{capabilities} impostato con \const{PR\_SET\_KEEPCAPS}. Introdotta a
- partire dal kernel 2.2.18.
+ il valore del flag di controllo delle \textit{capabilities} impostato con
+ \const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
\item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
- richiede i privilegi di amministratore (la \itindex{capabilities} capacità
- \const{CAP\_SETPCAP}), altrimenti la chiamata fallirà con un errore di
- \errval{EPERM}. Introdotta a partire dal kernel 2.6.26.
+ richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
+ altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
+ partire dal kernel 2.6.26.
\item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
funzione l'impostazione corrente per i \itindex{securebits}
projects / gapil.git / blobdiff