[ Pobierz całość w formacie PDF ]
.Aby to zrobiæ, j¹dro zmienia tzw.protokó³ obs³ugi (ang.line discipline) urz¹dzenia tty.Zarówno SLIP, jak i PPP s¹ pro-toko³ami obs³ugi, które mog¹ zostaæ w³¹czone na urz¹dzeniach tty.Ogólna zasadajest taka, ¿e sterownik szeregowy obs³uguje otrzymane dane w ró¿ny sposób, w za-le¿noSci od tego, z jakiego protoko³u obs³ugi korzysta.W przypadku domySlnegoprotoko³u obs³ugi sterownik po prostu przesy³a kolejno ka¿dy otrzymany znak.Gdy zostanie wybrany protokó³ obs³ugi PPP lub SLIP, sterownik nie czyta blokówdanych, ale opatruje je specjalnym nag³Ã³wkiem, który pozwala na identyfikacjê blo-ku danych w strumieniu po drugiej stronie i przes³anie nowego bloku danych.Narazie zrozumienie tego nie jest zbyt istotne.W dalszych rozdzia³ach omówimydok³adniej PPP i SLIP i wszystko stanie siê jasne.Dostêp do urz¹dzeñ szeregowychTak jak wszystkie urz¹dzenia w systemie Unix, tak i porty szeregowe s¹ dostêpnepoprzez specjalne pliki urz¹dzeñ znajduj¹ce siê w katalogu /dev.Istniej¹ dwa rodza-je plików urz¹dzeñ zwi¹zanych ze sterownikami szeregowymi i dla ka¿dego portuistnieje jeden taki plik.Zachowanie urz¹dzenia bêdzie zale¿a³o od tego, który z jegoplików otworzymy.Tutaj wska¿emy ró¿nice, co pomo¿e nam zrozumieæ pewnekonfiguracje.Jednak w praktyce wystarczy u¿ywaæ tylko jednego z tych plików.Nied³ugo jeden z nich mo¿e w ogóle przestaæ istnieæ.Wa¿niejsze urz¹dzenia z dwóch klas urz¹dzeñ szeregowych maj¹ numer nadrzêdny4, a pliki specjalne urz¹dzeñ nosz¹ nazwy ttyS0, ttyS1 itd.Drugi rodzaj ma numernadrzêdny 5 i zosta³ stworzony do wykorzystania przy dzwonieniu na zewn¹trzprzez port.Pliki specjalne w tym przypadku nosz¹ nazwy cua0, cua1 itd.W SwiecieUniksa liczenie generalnie rozpoczyna siê od zera, choæ inteligentni ludzie zwyklelicz¹ od jednego.Wprowadza to lekkie zamieszanie, poniewa¿COM1:jest reprez-entowany przez /dev/ttyS0,COM2:przez /dev/ttyS1 itd.Ka¿dy, kto zna architekturêsprzêtow¹ IBM PC wie, ¿e portCOM3:i porty o wiêkszych numerach nigdy nie sta³ysiê w rzeczywistoSci standardem.Urz¹dzenia cua, czyli s³u¿¹ce do dzwonienia (z ang.calling out), mia³y rozwi¹zaæproblem konfliktów urz¹dzeñ szeregowych przeznaczonych dla modemówi obs³uguj¹cych zarówno po³¹czenia przychodz¹ce, jak i wychodz¹ce.Niestety, sta³ysiê one xród³em innych k³opotów i zapewne trzeba bêdzie z nich zrezygnowaæ.Przyjrzyjmy siê pokrótce problemowi.Linux, podobnie jak Unix, pozwala, by urz¹dzenie lub inny plik by³y otwieraneprzez wiêcej ni¿ jeden proces jednoczeSnie.Niestety nie jest to zalet¹ w przypadku 50 Rozdzia³ 4: Konfigurowanie urz¹dzeñ szeregowychurz¹dzeñ tty, gdy¿ dwa procesy prawie na pewno bêd¹ sobie przeszkadza³y.NaszczêScie wymySlono 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 chceotworzyæ urz¹dzenie tty, sprawdza, czy w okreSlonym miejscu istnieje plik o nazwiepodobnej 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 samympliku ID procesu (pid), który stworzy³ plik blokuj¹cy.Wiêcej na ten temat powiemyza 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¿liwedopiero, gdy zosta³ zdefiniowany FSSTND (standard systemu plików Linuksa) zustalon¹ lokalizacj¹ plików blokuj¹cych, które zaczê³y wtedy dzia³aæ poprawnie dlaurz¹dzeñ tty.WczeSniej zdarzy³o siê, ¿e wspó³istnia³o kilka mo¿liwych lokalizacjiplikó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¹cez ró¿nych miejsc, a maj¹ce kontrolowaæ jedno urz¹dzenie tty.Efekt by³ taki, jakbypliki blokuj¹ce w ogóle nie by³y u¿ywane.Aby rozwi¹zaæ ten problem, stworzono urz¹dzenia cua.Zamiast polegaæ na plikachblokuj¹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óbaotwarcia 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êtapróba otwarcia urz¹dzenia ttyS, ¿¹danie by³o blokowane, to znaczy wstrzymywanedo czasu zamkniêcia urz¹dzenia cua przez inny proces
[ Pobierz całość w formacie PDF ]