Ludzie pragną czasami się rozstawać, żeby móc tęsknić, czekać i cieszyć się z powrotem.
Na
szczêœcie wymyœlono mechanizm pozwalaj¹cy sprawdzaæ procesowi, czy urz¹dze-
nie tty zosta³o ju¿ otwarte przez inny proces. Mechanizm ten wykorzystuje tak zwa-
ne pliki blokuj¹ce (ang. lock files). Dzia³a na nastêpuj¹cej zasadzie: gdy proces chce
otworzyæ urz¹dzenie tty, sprawdza, czy w okreœlonym miejscu istnieje plik o nazwie
podobnej do urz¹dzenia, które chce otworzyæ. Je¿eli plik nie istnieje, proces go two-
rzy i otwiera urz¹dzenie tty. Je¿eli plik istnieje, proces zak³ada, ¿e urz¹dzenie otwo-
rzy³ ju¿ inny proces i podejmuje stosowne dzia³anie. Jeszcze jeden pomys³ na spraw-
ne dzia³anie systemu zarz¹dzania plikami blokuj¹cymi to zapisywanie w samym
pliku ID procesu (pid), który stworzy³ plik blokuj¹cy. Wiêcej na ten temat powiemy
za chwilê.
Mechanizm pliku blokuj¹cego dzia³a doskonale w warunkach, gdy jest zdefiniowa-
ne miejsce dla takich plików i wszystkie programy wiedz¹, gdzie ich szukaæ. Nieste-
ty nie zawsze tak by³o w Linuksie. Korzystanie z tego mechanizmu sta³o siê mo¿liwe
dopiero, gdy zosta³ zdefiniowany FSSTND (standard systemu plików Linuksa) z
ustalon¹ lokalizacj¹ plików blokuj¹cych, które zaczê³y wtedy dzia³aæ poprawnie dla
urz¹dzeñ tty. Wczeœniej zdarzy³o siê, ¿e wspó³istnia³o kilka mo¿liwych lokalizacji
plików blokuj¹cych wybranych przez programistów: /usr/spool/locks/, /var/spool/locks/,
/var/lock/ i /usr/lock/. Zamieszanie rodzi³o chaos. Programy otwiera³y pliki blokuj¹ce
z ró¿nych miejsc, a maj¹ce kontrolowaæ jedno urz¹dzenie tty. Efekt by³ taki, jakby
pliki blokuj¹ce w ogóle nie by³y u¿ywane.
Aby rozwi¹zaæ ten problem, stworzono urz¹dzenia cua. Zamiast polegaæ na plikach
blokuj¹cych, które mia³y zabezpieczaæ przed kolidowaniem ze sob¹ programów ko-
rzystaj¹cych z urz¹dzeñ szeregowych, zdecydowano, ¿e to j¹dro bêdzie decydowaæ,
kto ma mieæ dostêp do urz¹dzenia. Je¿eli urz¹dzenie ttyS by³o ju¿ otwarte, próba
otwarcia cua koñczy³a siê b³êdem. Program móg³ go zinterpretowaæ jako informacjê,
¿e urz¹dzenie jest u¿ywane. Je¿eli urz¹dzenie cua by³o ju¿ otwarte i zosta³a podjêta
próba otwarcia urz¹dzenia ttyS, ¿¹danie by³o blokowane, to znaczy wstrzymywane
do czasu zamkniêcia urz¹dzenia cua przez inny proces. Dzia³a³o do ca³kiem dobrze,
je¿eli mia³eœ jeden modem skonfigurowany do odbierania po³¹czeñ i co jakiœ czas
chcia³eœ zadzwoniæ za pomoc¹ tego samego urz¹dzenia. K³opoty pojawi³y siê w œro-
dowiskach, gdzie wiele programów chcia³o dzwoniæ z tego samego urz¹dzenia. Je-
dynym sposobem na rozwi¹zanie tego problemu by³o zastosowanie plików blo-
kuj¹cych. Powrót do punktu wyjœcia.
Wystarczy wspomnieæ, ¿e przyszed³ tu z pomoc¹ standard systemu plików Linuksa.
Teraz pliki blokuj¹ce musz¹ znajdowaæ siê w katalogu /var/lock i nazywaæ zgodnie
z przyjêt¹ konwencj¹, czyli plik blokuj¹cy dla urz¹dzenia ttyS1 nazywa siê na
przyk³ad LCK..ttyS1. Pliki blokuj¹ce cua powinny tak¿e znajdowaæ siê w tym katalo-
gu, ale u¿ywanie urz¹dzeñ cua nie jest zalecane.
Przez jakiœ czas urz¹dzenia cua bêd¹ jeszcze funkcjonowa³y, by zapewniæ kompatybil-
noœæ w okresie przejœciowym, ale stopniowo bêd¹ wycofywane. Je¿eli zastanawiasz
siê, czego u¿ywaæ, trzymaj siê urz¹dzeñ ttyS i upewnij siê, ¿e twój system jest zgodny
z FSSTND lub ¿e przynajmniej wszystkie programy korzystaj¹ce z urz¹dzeñ szere-
gowych umieszczaj¹ pliki blokuj¹ce w tym samym miejscu. Wiêkszoœæ oprogramo-
Dostêp do urz¹dzeñ szeregowych
51
wania pracuj¹cego z urz¹dzeniami szeregowymi tty posiada opcjê kompilacyjn¹ po-
zwalaj¹c¹ na wskazanie miejsca umieszczania plików blokuj¹cych. Czêsto wystêpu-
je ona w postaci zmiennej o nazwie typu LOCKDIR w pliku Makefile lub w nag³ów-
kowym pliku konfiguracyjnym. Je¿eli sam kompilujesz oprogramowanie, najlepiej