sempre vera.}, un terminale di controllo. In generale questo viene fatto
automaticamente dal sistema\footnote{a meno di non avere richiesto
esplicitamente che questo non diventi un terminale di controllo con il flag
- \const{O\_NOCTTY} (vedi sez.~\ref{sec:file_open}). In questo Linux segue la
- semantica di SVr4; BSD invece richiede che il terminale venga allocato
- esplicitamente con una \func{ioctl} con il comando \const{TIOCSCTTY}.}
-quando viene aperto il primo terminale (cioè uno dei vari file di dispositivo
-\file{/dev/tty*}) che diventa automaticamente il terminale di controllo,
-mentre il processo diventa il \textsl{processo di controllo} di quella
-sessione.
+ \const{O\_NOCTTY} (vedi sez.~\ref{sec:file_open_close}). In questo Linux
+ segue la semantica di SVr4; BSD invece richiede che il terminale venga
+ allocato esplicitamente con una \func{ioctl} con il comando
+ \const{TIOCSCTTY}.} quando viene aperto il primo terminale (cioè uno dei
+vari file di dispositivo \file{/dev/tty*}) che diventa automaticamente il
+terminale di controllo, mentre il processo diventa il \textsl{processo di
+ controllo} di quella sessione.
In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
fine le differenze sono\footnote{in generale nel caso di login via rete o di
terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa
-i file standard (vedi sez.~\ref{sec:file_std_descr}) per l'I/O, tratteremo
+i file standard (vedi tab.~\ref{tab:file_std_files}) per l'I/O, tratteremo
solo il caso classico del terminale.
Abbiamo già brevemente illustrato in sez.~\ref{sec:intro_kern_and_sys} le
poi porsi in attesa dell'immissione del nome di un utente.
Una volta che si sia immesso il nome di login \cmd{getty} esegue direttamente
-il programma \cmd{login} con una \func{exevle}, passando come argomento la
+il programma \cmd{login} con una \func{execle}, passando come argomento la
stringa con il nome, ed un ambiente opportunamente costruito che contenga
quanto necessario; ad esempio di solito viene opportunamente inizializzata la
variabile di ambiente \envvar{TERM} per identificare il terminale su cui si
A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni
iniziali, come la stampa di messaggi di benvenuto o il controllo della posta)
ad eseguire con un'altra \func{exec} la shell, che si troverà con un ambiente
-già pronto con i file standard di sez.~\ref{sec:file_std_descr} impostati sul
+già pronto con i file standard di tab.~\ref{tab:file_std_files} impostati sul
terminale, e pronta, nel ruolo di leader di sessione e di processo di
controllo per il terminale, a gestire l'esecuzione dei comandi come illustrato
-in sez.~\ref{sec:sess_job_control_overview}.
+in sez.~\ref{sec:sess_job_control_overview}.
Dato che il processo padre resta sempre \cmd{init} quest'ultimo potrà
provvedere, ricevendo un \signal{SIGCHLD} all'uscita della shell quando la
\textit{syslog} è anche il kernel, che a sua volta può avere necessità di
inviare messaggi verso l'\textit{user space}. I messaggi del kernel sono
mantenuti in un apposito buffer circolare e generati all'interno del kernel
-tramite la funzione \func{printk}, analoga alla \func{printf} usata in
+tramite la funzione \texttt{printk}, analoga alla \func{printf} usata in
\textit{user space}.\footnote{una trattazione eccellente dell'argomento si
trova nel quarto capitolo di \cite{LinDevDri}.}
\label{fig:printk_priority}
\end{figure}
-Dato che i messaggi generati da \func{printk} hanno un loro specifico formato
-tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per leggerli,
-rimappare le priorità sui valori di tab.~\ref{tab:sess_syslog_priority} e
-inviarli al sistema del \textit{syslog} nella facility \const{LOG\_KERN}.
-Oggi i nuovi demoni più avanzati che realizzano il servizio (come
-\texttt{rsyslog} o \texttt{syslog-ng}) sono in grado di fare tutto questo da
-soli.
+Dato che i messaggi generati da \texttt{printk} hanno un loro specifico
+formato tradizionalmente si usava un demone ausiliario, \cmd{klogd}, per
+leggerli, rimappare le priorità sui valori di
+tab.~\ref{tab:sess_syslog_priority} e inviarli al sistema del \textit{syslog}
+nella facility \const{LOG\_KERN}. Oggi i nuovi demoni più avanzati che
+realizzano il servizio (come \texttt{rsyslog} o \texttt{syslog-ng}) sono in
+grado di fare tutto questo da soli.
Ma i messaggi del kernel non sono necessariamente connessi al sistema del
\textit{syslog}; ad esempio possono anche essere letti direttamente dal buffer
\item[\errcode{ERESTARTSYS}] l'operazione è stata interrotta da un segnale.
\item[\errcode{EPERM}] non si hanno i privilegi richiesti per l'operazione
richiesta.
- \item[\errcode{ENOSYS}] il supporto per \func{printk} non è stato compilato
+ \item[\errcode{ENOSYS}] il supporto per \texttt{printk} non è stato compilato
nel kernel.
\end{errlist}
ed inoltre \errval{EBADF} ed \errval{ENOSYS}.
-\subsection{L'architettura}
-\label{sec:term_design}
+\subsection{L'architettura dell'I/O su terminale}
+\label{sec:term_io_design}
I terminali sono una classe speciale di dispositivi a caratteri (si ricordi la
classificazione di sez.~\ref{sec:file_file_types}); un terminale ha infatti una
dette rispettivamente ``\textsl{modo canonico}'' e ``\textsl{modo non
canonico}'', che hanno dei comportamenti nettamente diversi.
+% TODO: inserire qui il comportamento di read relativo all'errore EIO sulla
+% lettura in background???
+
La modalità preimpostata all'apertura del terminale è quella canonica, in cui
le operazioni di lettura vengono sempre effettuate assemblando i dati in una
linea;\footnote{per cui eseguendo una \func{read} su un terminale in modo
e che le linee di controllo del modem devono essere
ignorate. Se non impostato effettuando una chiamata ad
\func{open} senza aver specificato il flag di
- \const{O\_NOBLOCK} si bloccherà il processo finché
+ \const{O\_NONBLOCK} si bloccherà il processo finché
non si è stabilita una connessione con il modem; inoltre
se viene rilevata una disconnessione viene inviato un
segnale di \signal{SIGHUP} al processo di controllo del
% LocalWords: NOCTTY TIOCSCTTY error tcsetpgrp termios fd pgrpid descriptor VT
% LocalWords: ENOTTY ENOSYS EBADF SIGTTIN SIGTTOU EIO tcgetpgrp crypt SIGTSTP
% LocalWords: SIGINT SIGQUIT SIGTERM SIGHUP hungup kill orphaned SIGCONT exit
-% LocalWords: init Slackware run level inittab fig device getty exevle TERM at
+% LocalWords: init Slackware run level inittab fig device getty TERM at
% LocalWords: getpwnam chdir home chown chmod setuid setgid initgroups SIGCHLD
% LocalWords: daemon like daemons NdT Stevens Programming FAQ filesystem umask
% LocalWords: noclose syslog syslogd socket UDP klogd printk printf facility
% LocalWords: BRKINT IGNCR carriage return newline ICRNL INLCR IUCLC IXON NL
% LocalWords: IXANY IXOFF IMAXBEL iflag OPOST CR OCRNL OLCUC ONLCR ONOCR OFILL
% LocalWords: ONLRET OFDEL NLDLY CRDLY TABDLY BSDLY backspace BS VTDLY FFDLY
-% LocalWords: form feed FF oflag CLOCAL NOBLOCK of HUPCL CREAD CSTOPB PARENB
+% LocalWords: form feed FF oflag CLOCAL of HUPCL CREAD CSTOPB PARENB
% LocalWords: PARODD CSIZE CS CBAUD CBAUDEX CIBAUD CRTSCTS RTS CTS cflag ECHO
% LocalWords: ICANON ECHOE ERASE ECHOPRT ECHOK ECHOKE ECHONL ECHOCTL ctrl ISIG
% LocalWords: INTR QUIT SUSP IEXTEN EOL LNEXT REPRINT WERASE NOFLSH and TOSTOP