%% session.tex
%%
-%% Copyright (C) 2000-2018 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2024 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",
non addirittura le telescriventi). Oggi questa interfaccia viene in genere
emulata o tramite programmi o con le cosiddette console virtuali associate a
monitor e tastiera, ma esiste sempre la possibilità di associarla direttamente
-ad alcuni dispositivi, come eventuali linee seriali, ed in certi casi, come
-buona parte dei dispositivi embedded su cui gira Linux (come router, access
-point, ecc.) questa resta anche l'unica opzione per una \textit{console} di
+a dispositivi specifici lelinee seriali, che in certi casi, come avviene per
+buona parte dei dispositivi embedded su cui gira Linux come router, access
+point, ecc. sono l'unica opzione per una avere una \textit{console} di
sistema.
sistema è nato prima dell'esistenza di tutto ciò.
Il \textit{job control} è una caratteristica opzionale, introdotta in BSD
-negli anni '80, e successivamente standardizzata da POSIX.1. La sua
+negli anni '80, e successivamente standardizzata da POSIX.1; la sua
disponibilità nel sistema è verificabile attraverso il controllo della macro
\macro{\_POSIX\_JOB\_CONTROL}. In generale il \textit{job control} richiede il
supporto sia da parte della shell (quasi tutte ormai lo hanno), che da parte
La versione illustrata è quella usata nella definizione di POSIX.1, in BSD
viene usata una funzione con questo nome, che però è identica a
-\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. Nelle
+\func{setpgid}, che vedremo a breve, negli argomenti e negli effetti. Nella
\acr{glibc} viene sempre usata sempre questa definizione, a meno di non
richiedere esplicitamente la compatibilità all'indietro con BSD, definendo la
macro \macro{\_BSD\_SOURCE} ed evitando di definire le macro che richiedono
L'organizzazione del sistema del job control è strettamente connessa alle
modalità con cui un utente accede al sistema per dare comandi, collegandosi ad
esso con un terminale, che sia questo realmente tale, come un VT100 collegato
-ad una seriale o virtuale, come quelli associati a schermo e tastiera o ad una
+ad una seriale, o virtuale, come quelli associati a schermo e tastiera o ad una
connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
fine le differenze sono nel dispositivo cui il kernel associa i file standard
(vedi tab.~\ref{tab:file_std_files}) per l'I/O, tratteremo solo il caso
senza nessun intervento dell'utente, sono normalmente chiamati
\textsl{demoni}, (o \textit{daemons}), nome ispirato dagli omonimi spiritelli
della mitologia greca che svolgevano compiti che gli dei trovavano noiosi, di
-cui parla anche Socrate (che sosteneva di averne uno al suo servizio).
+cui parla anche Socrate, che sosteneva di averne uno al suo servizio.
%TODO ricontrollare, i miei ricordi di filosofia sono piuttosto datati.
Se però si lancia un programma demone dalla riga di comando in un sistema che
-supporta, come Linux, il \textit{job control} esso verrà comunque associato ad
+supporta il \textit{job control} come Linux, esso verrà comunque associato ad
un terminale di controllo e mantenuto all'interno di una sessione, e anche se
può essere mandato in background e non eseguire più nessun I/O su terminale,
si avranno comunque tutte le conseguenze che abbiamo trattato in
In Linux buona parte di queste azioni possono venire eseguite invocando la
-funzione \funcd{daemon} (fornita dalle \acr{glibc}), introdotta per la prima
+funzione \funcd{daemon} (fornita dalla \acr{glibc}), introdotta per la prima
volta in BSD4.4; il suo prototipo è:
\begin{funcproto}{
le modalità con cui queste azioni vengono realizzate dipendono ovviamente dal
demone che si usa, per la gestione del quale si rimanda ad un testo di
amministrazione di sistema.\footnote{l'argomento è ad esempio coperto dal
- capitolo 3.2.3 si \cite{AGL}.}
+ capitolo 3.2.3 di \cite{AGL}.}
-Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
+La \acr{glibc} definisce una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
funzionano solo localmente; se si vogliono inviare i messaggi ad un altro
sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
specificabile attraverso le costanti riportate in
tab.~\ref{tab:sess_syslog_priority}.
-Le \acr{glibc}, seguendo POSIX.1-2001, prevedono otto diverse priorità
+La \acr{glibc}, seguendo POSIX.1-2001, prevede otto diverse priorità
ordinate da 0 a 7, in ordine di importanza decrescente; questo comporta che i
tre bit meno significativi dell'argomento \param{priority} sono occupati da
questo valore, mentre i restanti bit più significativi vengono usati per
Per la lettura dei messaggi del kernel e la gestione del relativo buffer
circolare esiste una apposita \textit{system call} chiamata anch'essa
\texttt{syslog}, ma dato il conflitto di nomi questa viene rimappata su
- un'altra funzione di libreria, in particolare nelle \acr{glibc} essa viene
- invocata tramite la funzione \funcd{klogctl},\footnote{nelle \acr{libc4} e
- nelle \acr{libc5} la funzione invece era \code{SYS\_klog}.} il cui prototipo
+ un'altra funzione di libreria, in particolare nella \acr{glibc} essa viene
+ invocata tramite la funzione \funcd{klogctl},\footnote{nella \acr{libc4} e
+ nella \acr{libc5} la funzione invece era \code{SYS\_klog}.} il cui prototipo
è:
\begin{funcproto}{
\label{sec:sess_terminal_io}
Benché come ogni altro dispositivo i terminali siano accessibili come file,
-essi hanno assunto storicamente, essendo stati a lungo l'unico modo di
-accedere al sistema, una loro rilevanza specifica, che abbiamo già avuto modo
-di incontrare nella precedente sezione.
+essendo stati a lungo l'unico modo di accedere al sistema essi hanno assunto
+storicamente una loro rilevanza specifica, che abbiamo già avuto modo di
+incontrare nella precedente sezione.
Esamineremo qui le peculiarità dell'I/O eseguito sui terminali, che per la
loro particolare natura presenta delle differenze rispetto ai normali file su
stringa che deve essere restituita, compreso lo zero di terminazione finale,
eccede questa dimensione si avrà un errore.
-Una funzione funzione analoga alle precedenti prevista da POSIX.1, che
-restituisce il nome di un file di dispositivo, è \funcd{ctermid}, il cui
-prototipo è:
+Una funzione analoga alle precedenti prevista da POSIX.1, che restituisce il
+nome di un file di dispositivo, è \funcd{ctermid}, il cui prototipo è:
\begin{funcproto}{
\fhead{stdio.h}
}
{La funzione ritorna il puntatore alla stringa contenente il \textit{pathname}
- del terminale o \val{NULL} se non non riesce ad eseguire l'operazione, non
- sono previsti errori.}
+ del terminale o \val{NULL} se non riesce ad eseguire l'operazione, non sono
+ previsti errori.}
\end{funcproto}
La funzione restituisce un puntatore al \textit{pathname} del file di
chiamare \func{tcsetattr}.
Si tenga presente che per le linee seriali solo alcuni valori di velocità sono
-validi; questi possono essere specificati direttamente (le \acr{glibc}
-prevedono che i valori siano indicati in bit per secondo), ma in generale
-altre versioni di librerie possono utilizzare dei valori diversi. Per questo
+validi; questi possono essere specificati direttamente (la \acr{glibc}
+prevede che i valori siano indicati in bit per secondo), ma in generale
+altre versioni di libreria possono utilizzare dei valori diversi. Per questo
POSIX.1 prevede una serie di costanti che però servono solo per specificare le
velocità tipiche delle linee seriali:
\begin{verbatim}
del terminale quest'ultimo non potrà funzionare: quando il terminale non è
seriale il valore non influisce sulla velocità di trasmissione dei dati.
-In generale impostare un valore nullo (\val{B0}) sulla linea di output fa si
+In generale impostare un valore nullo (\val{B0}) sulla linea di output fa sì
che il modem non asserisca più le linee di controllo, interrompendo di fatto
la connessione, qualora invece si utilizzi questo valore per la linea di input
l'effetto sarà quello di rendere la sua velocità identica a quella della linea
projects / gapil.git / blobdiff