Ocenite etot tekst:Ne chital10987654321
SoderzhanieFine HTMLPrinted versiontxt(Word,KPK)Lib.ru html
Sistemnaya arhitektura QNX4

---------------------------------------------------------------
     (S) QNX Software Systems Ltd., 1996
     Avtor: QNX Software Systems Ltd.
     Russkoe izdanie: SWD Software Ltd.
     WWW: http://www.swd.ru/qnx/support/literature/sysarch/
     E-mail: books.qnx@swd.ru
     Date: 04 Mar 2002
---------------------------------------------------------------



Vpervye na russkom yazyke kniga o QNX.
Rob Kerten "Vvedenie v QNX/Neutrino 2". Annotaciya,
Zakaz pechatnoj versii(400 r.)

Sistemnaya arhitektura QNX4


Kniga Sistemnaya arhitektura soprovozhdaet operacionnuyu
sistemu QNX i prednaznachena kak dlya razrabotchikov prilozhenij, tak i dlya
konechnyh pol'zovatelej.
V knige podrobno rassmatrivaetsya struktura i funkcii
QNX. V nej opisany mikroyadro, sistemnye menedzhery, a takzhe unikal'nyj
mehanizm svyazi mezhdu processami, osnovannyj  na peredache soobshchenij.
Prezhde chem ispol'zovat' QNX, rekomenduetsya snachala prochitat' etu knigu.

Za informaciej ob ustanovke i ispol'zovanii QNX,
obratites' k knige Rukovodstvo pol'zovatelya OS QNX
Sistemnaya arhitektura soderzhit sleduyushchie glavy:

 Koncepciya QNX;
 Mikroyadro;
 Menedzher processov;
 Prostranstvo imen vvoda/vyvoda;
 Menedzher fajlovoj sistemy;
 Menedzher ustrojstv;
 Menedzher seti;
 Okonnaya sistema Photon microGUI.








 
Koncepciya QNX

|ta glava ohvatyvaet sleduyushchie temy:
chto takoe QNX?;
arhitektura mikroyadra;
svyaz' mezhdu processami (IPC);
QNX kak set'.



CHto takoe QNX?

Glavnaya obyazannost' operacionnoj sistemy sostoit v upravlenii
resursami komp'yutera. Vse dejstviya v sisteme - dispetcherizaciya
prikladnyh programm, zapis' fajlov na disk, peresylka dannyh po seti i
t.p. - dolzhny vypolnyat'sya sovmestno nastol'ko slitno i prozrachno,
naskol'ko eto vozmozhno.

Nekotorye oblasti primeneniya pred®yavlyayut bolee zhestkie trebovaniya
k upravleniyu resursami i dispetcherizacii programm, chem drugie.
Prilozheniya real'nogo vremeni, naprimer, polagayutsya na sposobnost'
operacionnoj sistemy obrabatyvat' mnogochislennye sobytiya v predelah
ogranichennogo intervala vremeni. CHem bystree reagiruet operacionnaya
sistema, tem bol'shee prostranstvo dlya manevra imeet prilozhenie
real'nogo vremeni v predelah zhestkih vremennyh ramok.

Operacionnaya sistema QNX ideal'na dlya prilozhenij real'nogo
vremeni. Ona obespechivaet vse neot®emlemye sostavlyayushchie sistemy
real'nogo vremeni:  mnogozadachnost', dispetcherizaciyu programm na
osnove prioritetov i bystroe pereklyuchenie konteksta.

QNX - udivitel'no gibkaya sistema. Razrabotchiki legko mogut
nastroit' operacionnuyu sistemu takim obrazom, chtoby ona otvechala
trebovaniyam konkretnyh prilozhenij. QNX pozvolyaet vam sozdat' sistemu,
ispol'zuyushchuyu tol'ko neobhodimye dlya resheniya vashej zadachi resursy.
Konfiguraciya sistemy mozhet izmenyat'sya v shirokom diapazone - ot yadra s
neskol'kimi nebol'shimi modulyami do polnocennoj setevoj sistemy,
obsluzhivayushchej sotni pol'zovatelej.

QNX dostigaet svoego unikal'nogo urovnya proizvoditel'nosti,
modul'nosti i prostoty blagodarya dvum fundamental'nym principam:

 arhitektura na osnove mikroyadra;
 svyaz' mezhdu processami na osnove soobshchenij.


Arhitektura mikroyadra sistemy QNX
QNX sostoit iz nebol'shogo yadra, koordiniruyushchego rabotu
vzaimodejstvuyushchih processov. Kak pokazano na risunke, struktura bol'she
napominaet ne ierarhiyu, a komandu, v kotoroj neskol'ko igrokov odnogo
urovnya vzaimodejstvuyut mezhdu soboj i so svoim "zashchitnikom" - yadrom.





Mikroyadro sistemy QNX koordiniruet rabotu sistemnyh menedzherov.



Nastoyashchee yadro
YAdro - eto "serdce" lyuboj operacionnoj sistemy.
V nekotoryh operacionnyh sistemah na nego vozlagaetsya tak mnogo
funkcij, chto yadro, po suti, zamenyaet vsyu operacionnuyu sistemu!

V QNX zhe Mikroyadro - eto nastoyashchee yadro. Vo-pervyh, kak i sleduet
yadru real'nogo vremeni, yadro QNX imeet ochen' malen'kij razmer.
Vo-vtoryh, ono vypolnyaet dve vazhnejshie funkcii:

peredacha soobshchenij - Mikroyadro  obespechivaet
marshrutizaciyu vseh soobshchenij mezhdu vsemi processami v sisteme;
dispetcherizaciya - planirovshchik - eto chast'
Mikroyadra, i on poluchaet upravlenie vsyakij raz, kogda process izmenyaet
svoe sostoyanie v rezul'tate polucheniya soobshcheniya ili preryvaniya.

V otlichie ot vseh ostal'nyh processov, yadro nikogda ne poluchaet
upravleniya v rezul'tate dispetcherizacii.  Vhodyashchij v sostav yadra kod
vypolnyaetsya tol'ko v rezul'tate pryamyh vyzovov iz processa ili
apparatnogo preryvaniya.


Sistemnye processy
Vse uslugi operacionnoj sistemy,  za  isklyucheniem  teh,  kotorye
vypolnyayutsya  yadrom,  v QNX predostavlyayutsya cherez standartnye processy.
Tipichnaya konfiguraciya QNX imeet sleduyushchie sistemnye processy:

 Menedzher processov (Proc);
 Menedzher fajlovoj sistemy (Fsys);
 Menedzher ustrojstv (Dev);
 Menedzher seti (Net).
Sistemnye i pol'zovatel'skie processy
Sistemnye processy prakticheski nichem ne otlichayutsya ot lyubyh
napisannyh pol'zovatelem programm - oni ne imeyut kakogo-libo skrytogo
ili osobogo interfejsa, nedostupnogo pol'zovatel'skim processam.

Imenno za schet takoj sistemnoj arhitektury QNX obladaet
unikal'noj narashchivaemost'yu. Tak kak bol'shinstvo uslug operacionnoj
sistemy predostavlyayutsya standartnymi processami QNX, to rasshirenie
operacionnoj sistemy trebuet vsego lish' napisaniya novoj programmy,
obespechivayushchej novuyu uslugu!

Fakticheski, granica mezhdu operacionnoj sistemoj i prikladnoj
programmoj mozhet byt' ochen' razmyta. Edinstvennyj kriterij, po kotoromu
my mozhem otlichit' prikladnye processy i sistemnye servisnye processy,
sostoit v tom, chto process operacionnoj sistemy upravlyaet kakim-libo
resursom v interesah prikladnogo processa.

Predpolozhim, chto vy napisali server bazy dannyh. Kak zhe dolzhen
byt' klassificirovan etot process?

Tochno tak zhe, kak server fajlovoj sistemy prinimaet zaprosy (v QNX
realizovannye cherez mehanizm soobshchenij) na otkrytie fajlov i zapis'
ili chtenie dannyh, eto budet delat' i server bazy dannyh. Hotya zaprosy
k serveru bazy dannyh mogut byt' i bolee slozhnymi, shodstvo oboih
serverov zaklyuchaetsya v tom, chto oba oni obespechivayut dostup k resursu
posredstvom zaprosov.  Oba oni yavlyayutsya nezavisimymi processami,
kotorye mogut byt' napisany pol'zovatelem i zapuskat'sya po mere
neobhodimosti.

Server bazy dannyh mozhet rassmatrivat'sya kak process v odnom
sluchae i kak prilozhenie v drugom. |to dejstvitel'no ne imeet
znacheniya! Vazhno to, chto sozdanie i vypolnenie takih processov v QNX ne
trebuet absolyutno nikakih izmenenij v standartnyh komponentah
operacionnoj sistemy.


Drajvery ustrojstv
Drajvery ustrojstv - eto processy, kotorye yavlyayutsya posrednikami
mezhdu operacionnoj sistemoj i ustrojstvami i izbavlyayut operacionnuyu
sistemu ot neobhodimosti imet' delo s osobennostyami konkretnyh
ustrojstv.

Tak kak drajvery zapuskayutsya kak obychnye processy, dobavlenie
novogo drajvera v QNX ne vliyaet na drugie chasti operacionnoj sistemy.
Takim obrazom, dobavlenie novogo drajvera v QNX ne trebuet nichego,
krome neposredstvenno zapuska etogo drajvera.

Posle zapuska i zaversheniya procedury inicializacii, drajver mozhet
vybrat' odin iz dvuh variantov povedeniya:

stat' rasshireniem opredelennogo sistemnogo processa;
prodolzhat' vypolnenie kak nezavisimyj process.


Svyaz' mezhdu processami (IPC)
V tipichnoj dlya mnogozadachnoj sistemy real'nogo vremeni situacii,
kogda neskol'ko processov vypolnyayutsya odnovremenno, operacionnaya
sistema dolzhna predostavit' mehanizmy, pozvolyayushchie im obshchat'sya drug s
drugom.

Svyaz' mezhdu processami (Interprocess communication, sokrashchenno
IPC) yavlyaetsya klyuchom k razrabotke prilozhenij kak sovokupnosti
processov, v kotoryh kazhdyj process vypolnyaet otvedennuyu emu chast'
obshchej zadachi.

QNX predostavlyaet prostoj, no moshchnyj nabor vozmozhnostej IPC,
kotorye sushchestvenno oblegchayut razrabotku prilozhenij, sostoyashchih iz
vzaimodejstvuyushchih processov.


Peredacha soobshchenij
QNX byla pervoj kommercheskoj operacionnoj sistemoj svoego klassa,
kotoraya ispol'zovala peredachu soobshchenij v kachestve osnovnogo sposoba
IPC. Imenno posledovatel'noe voploshchenie metoda peredachi soobshcheniya v
masshtabah vsej operacionnoj sistemy obuslovlivaet moshchnost', prostotu i
elegantnost' QNX.

Soobshcheniya v QNX - eto posledovatel'nost' bajt, peredavaemyh ot
odnogo processa drugomu. Operacionnaya sistema ne pytaetsya
analizirovat' soderzhanie soobshcheniya - peredavaemye dannye imeyut smysl
tol'ko dlya otpravitelya i poluchatelya, i ni dlya kogo bolee.

Peredacha soobshcheniya pozvolyaet ne tol'ko obmenivat'sya dannymi, no i
yavlyaetsya sposobom sinhronizacii vypolneniya neskol'kih processov. Kogda
oni posylayut, poluchayut ili otvechayut na soobshcheniya, processy
preterpevayut razlichnye "izmeneniya sostoyaniya", kotorye vliyayut na to,
kogda i kak dolgo oni mogut vypolnyat'sya.  Znaya sostoyaniya i prioritety
processov, yadro organizuet ih dispetcherizaciyu takim obrazom, chtoby
maksimal'no effektivno ispol'zovat' resursy central'nogo processora
(CP).

Prilozhenie real'nogo vremeni i drugie otvetstvennye prilozheniya po
pravu nuzhdayutsya v nadezhnom mehanizme peredachi soobshchenij, t.k. vhodyashchie
v sostav etih prilozhenij processy tesno vzaimosvyazany. Realizovannyj v
QNX  mehanizm peredachi soobshchenij sposobstvuet uporyadocheniyu i povysheniyu
nadezhnosti programm.


QNX kak set'
V prostejshem sluchae lokal'naya set' obespechivaet razdelyaemyj
dostup k fajlam i periferijnym ustrojstvam dlya neskol'kih soedinennyh
mezhdu soboj komp'yuterov. QNX idet gorazdo dal'she etogo prostejshego
predstavleniya i ob®edinyaet vsyu set' v edinyj odnorodnyj nabor
resursov.

Lyuboj process na lyubom komp'yutere v sostave seti mozhet
neposredstvenno ispol'zovat' lyuboj resurs na lyubom drugom komp'yutere.
S tochki zreniya prilozhenij, ne sushchestvuet nikakoj raznicy mezhdu mestnym
ili udalennym resursom, i ispol'zovanie udalennyh resursov ne trebuet
kakih-libo special'nyh sredstv.  Bolee togo, chtoby opredelit',
nahoditsya li takoj resurs kak fajl ili ustrojstvo na lokal'nom
komp'yutere ili na drugom uzle seti, v programmu potrebuetsya vklyuchit'
special'nyj dopolnitel'nyj kod!

Pol'zovateli mogut imet' dostup k fajlam po vsej seti,
ispol'zovat' lyuboe periferijnoe ustrojstvo, zapuskat' programmy na
lyubom komp'yutere seti (pri uslovii, chto oni imeyut nadlezhashchie
polnomochiya). Svyaz' mezhdu processami osushchestvlyaetsya edinoobrazno,
nezavisimo ot ih mestopolozheniya v seti.  V osnove takoj prozrachnoj
podderzhki seti v QNX lezhit vseob®emlyushchaya koncepciya IPC na osnove
peredachi soobshchenij.


Model' edinogo komp'yutera
QNX iznachal'no proektirovalsya kak setevaya operacionnaya sistema. V
nekotoryh otnosheniyah QNX set' napominaet skoree bol'shuyu |VM, nezheli
nabor mini-komp'yuterov. Pol'zovatelyam izvestno, chto v rasporyazhenii
lyuboj iz prikladnyh programm imeetsya bol'shoj nabor resursov. No v
otlichie ot bol'shoj |VM, QNX obespechivaet bystruyu reakciyu sistemy, t.k.
sootvetstvuyushchij ob®em vychislitel'nyh resursov mozhet byt' vydelen na
kazhdom uzle v sootvetstvii s potrebnostyami kazhdogo pol'zovatelya.

V usloviyah upravleniya proizvodstvom ispol'zuyutsya programmiruemye
kontrollery i drugie ustrojstva vvoda/vyvoda, a takzhe kompleksy programm,
rabotayushchie v rezhime real'nogo vremeni, kotorym mozhet potrebovat'sya bol'she
resursov, chem drugim menee otvetstvennym prilozheniyam, takim kak tekstovyj
redaktor. Set' QNX dostatochno "otzyvchiva", chtoby podderzhivat'
odnovremenno oba etih tipa prilozhenij, QNX pozvolyaet sfokusirovat'
vychislitel'nuyu moshchnost' sistemy na proizvodstvennom oborudovanii (tam, gde
eto neobhodimo), v to zhe vremya, ne zhertvuya interfejsom pol'zovatelya.


Gibkaya podderzhka seti
QNX set' mozhet byt' postroena s ispol'zovaniem razlichnogo
oborudovaniya i standartnyh promyshlennyh protokolov. V silu svoej
polnoj prozrachnosti dlya prikladnyh programm i pol'zovatelej, novye
setevye arhitektury mogut byt' vnedreny v lyuboe vremya, ne razrushaya
operacionnoj sistemy.





Spisok podderzhivaemogo QNX setevogo oborudovaniya popolnyaetsya so
vremenem. Dlya polucheniya podrobnoj informacii obratites' k dokumentacii
na setevoe oborudovanie, kotoroe vy ispol'zuete.





Kazhdomu uzlu QNX seti prisvaivaetsya unikal'nyj nomer, kotoryj
stanovitsya ego identifikatorom. |tot nomer takzhe edinstvennyj vidimyj
priznak togo, funkcioniruet QNX kak set' ili kak odnoprocessornaya
operacionnaya sistema.

Takaya stepen' prozrachnosti yavlyaetsya eshche odnim primerom bol'shih
vozmozhnostej arhitektury QNX, osnovannoj na peredache soobshchenij. Vo
mnogih operacionnyh sistemah takie vazhnye funkcii kak podderzhka seti,
IPC ili dazhe peredacha soobshchenij vypolneny v vide nadstroek nad
operacionnoj sistemoj, a ne integrirovany neposredstvenno v ee
serdcevinu. Rezul'tatom takogo podhoda yavlyaetsya neuklyuzhij i
neeffektivnyj interfejs s "dvojnym standartom", kogda svyaz' mezhdu
processami - eto odno delo, v to vremya kak proniknovenie v skrytyj
interfejs tainstvennogo monolitnogo yadra - sovershenno drugoe delo!

QNX, naprotiv, ishodit iz togo, chto effektivnaya svyaz' yavlyaetsya
klyuchom k effektivnoj rabote. Peredacha soobshchenij yavlyaetsya, takim obrazom,
kraeugol'nym kamnem arhitektury QNX, uvelichivaet effektivnost' vseh
bez isklyucheniya tranzakcij mezhdu processami v sisteme, nezavisimo ot
togo, idet li rech' o peredache dannyh po vnutrennej shine personal'nogo
komp'yutera ili po koaksial'nomu kabelyu na rasstoyanie neskol'kih mil'.

Teper' davajte perejdem k bolee podrobnomu rassmotreniyu struktury
QNX.













Mikroyadro

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
svyaz' mezhdu processami (IPC);
IPC posredstvom soobshchenij;
IPC posredstvom proksi;
IPC posredstvom signalov;
IPC v seti;
IPC posredstvom semaforov;
dispetcherizaciya processov;
neskol'ko slov o real'nom vremeni.
 


Vvedenie
Mikroyadro QNX otvechaet za vypolnenie sleduyushchih funkcij:
svyaz' mezhdu processami - Mikroyadro upravlyaet marshrutizaciej
soobshchenij; ono takzhe podderzhivaet dve drugie formy IPC -
proksi i signaly;

setevoj interfejs nizkogo urovnya - Mikroyadro osushchestvlyaet
dostavku vseh soobshchenij, prednaznachennyh dlya processov na drugih uzlah
seti;

dispetcherizaciya processov - vhodyashchij v sostav YAdra
planirovshchik reshaet, kakomu iz zapushchennyh processov dolzhno byt'
peredano upravlenie;

pervichnaya obrabotka preryvanij - vse apparatnye preryvaniya i
isklyucheniya snachala prohodyat cherez Mikroyadro, a zatem peredayutsya
sootvetstvuyushchemu drajveru ili sistemnomu menedzheru.





Vnutri mikroyadra QNX.



Svyaz' mezhdu processami
Mikroyadro QNX podderzhivaet tri vazhnejshie formy svyazi mezhdu
processami: soobshcheniya, proksi i signaly.

Soobshcheniya - eto osnovopolagayushchaya forma IPC v QNX.
Oni obespechivayut sinhronnuyu svyaz' mezhdu vzaimodejstvuyushchimi processami,
kogda processu, posylayushchemu soobshchenie, trebuetsya poluchit'
podtverzhdenie togo, chto ono polucheno i, vozmozhno, otvet.

Proksi - eto osobyj vid soobshcheniya. Oni bol'she vsego
podhodyat dlya izveshcheniya o nastuplenii kakogo-libo sobytiya, kogda processu,
posylayushchemu soobshchenie, ne trebuetsya vstupat' v dialog s poluchatelem.

Signaly - eto tradicionnaya forma IPC. Oni
ispol'zuyutsya dlya asinhronnoj svyazi mezhdu processami.



IPC posredstvom soobshchenij
Soobshcheniya v QNX - eto pakety bajt, kotorye sinhronno
peredayutsya ot odnogo processa k drugomu. QNX pri etom ne  analiziruet
soderzhanie soobshcheniya. Peredavaemye dannye ponyatny tol'ko otpravitelyu i
poluchatelyu i nikomu bolee.


Primitivy peredachi soobshchenij
Dlya neposredstvennoj svyazi drug s drugom vzaimodejstvuyushchie
processy ispol'zuyut sleduyushchie funkcii yazyka programmirovaniya Si:


Funkciya yazyka Si:
Naznachenie:
Send()
posylka soobshchenij
Receive()
poluchenie soobshchenij
Reply()
otvet processu, poslavshemu soobshchenie

|ti funkcii mogut byt' ispol'zovany kak lokal'no,  t.e. dlya svyazi
mezhdu processami na odnom komp'yutere,  tak i v predelah seti, t.e. dlya
svyazi mezhdu processami na raznyh uzlah.

Sleduet zametit', odnako, chto daleko ne vsegda voznikaet
neobhodimost' ispol'zovat' funkcii Send(), Receive() i
Reply() v yavnom vide. Biblioteka funkcij yazyka Si v QNX postroena
na osnove ispol'zovaniya soobshchenij - v rezul'tate, kogda process ispol'zuet
standartnye mehanizmy peredachi dannyh (takie, kak, naprimer, programmnyj
kanal - pipe), on kosvennym obrazom ispol'zuet peredachu soobshchenij.





Process A posylaet soobshchenie processu B, kotoryj poluchaet ego,
obrabatyvaet i posylaet otvet




Na risunke izobrazhena posledovatel'nost' sobytij, imeyushchih mesto,
kogda dva processa, process A i process B, ispol'zuyut funkcii
Send(), Receive() i Reply() dlya svyazi drug s drugom:



 Process A posylaet soobshchenie processu B, vyzvav funkciyu Send(),
kotoraya peredaet sootvetstvuyushchij zapros yadru. V etot moment vremeni
process  A perehodit v SEND-blokirovannoe sostoyanie i ostaetsya v etom
sostoyanii do teh por, poka process B ne vyzovet funkciyu Receive()
dlya polucheniya soobshcheniya.

 Process B vyzyvaet Receive() i poluchaet soobshchenie ot
processa A. Pri etom sostoyanie processa A izmenyaetsya na REPLY-blokirovan.
Process B pri vyzove funkcii Receive() v dannom sluchae ne blokiruetsya,
t.k. k etomu momentu ego uzhe ozhidalo soobshchenie ot processa A.

Zamet'te, chto esli by process B vyzval Receive() do togo, kak
emu bylo poslano soobshchenie, to on by popal v sostoyanie RECEIVE-blokirovan do
polucheniya soobshcheniya. V etom sluchae process-otpravitel' soobshcheniya
nemedlenno posle posylki soobshcheniya popal by v sostoyanie
REPLY-blokirovan.
 Process B vypolnyaet obrabotku poluchennogo ot processa A
soobshcheniya i zatem vyzyvaet funkciyu Reply(). Otvetnoe soobshchenie
peredaetsya processu A, kotoryj perehodit v sostoyanie gotovnosti k
vypolneniyu. Vyzov Reply() ne blokiruet process B, kotoryj takzhe gotov
k vypolneniyu. Kakoj iz etih processov budet vypolnyat'sya, zavisit ot ih
prioritetov.



Sinhronizaciya processov
Peredacha soobshchenij ne tol'ko pozvolyaet processam obmenivat'sya
dannymi, no i predostavlyaet mehanizm sinhronizacii vypolneniya
neskol'kih vzaimodejstvuyushchih processov.

Davajte snova rassmotrim privedennyj vyshe risunok. Posle togo kak
process A vyzval funkciyu Send(), on ne mozhet prodolzhat' vypolnenie
do teh por, poka ne poluchit otvet na poslannoe soobshchenie. |to
garantiruet, chto vypolnyaemaya processom B po zaprosu processa A
obrabotka dannyh budet zavershena prezhde, chem process A prodolzhit
vypolnenie. Bolee togo, posle vyzova processom B zaprosa na poluchenie
dannyh Receive(), on ne mozhet prodolzhat' vypolnenie do teh por,
poka ne poluchit sleduyushchee soobshchenie.





Bolee podrobno dispetcherizaciya processov v QNX rassmatrivaetsya v
razdele "Dispetcherizaciya processov"
dalee v etoj glave.




Blokirovannye sostoyaniya
Kogda processu ne razreshaetsya prodolzhat' vypolnenie, t.k. on
dolzhen ozhidat' okonchaniya opredelennoj stadii protokola peredachi
soobshcheniya, - process nazyvaetsya blokirovannym.

Vozmozhnye blokirovannye sostoyaniya processov privedeny v sleduyushchej
tablice:


Esli process vydal:
To process:
Zapros Send(), i otpravlennoe im soobshchenie eshche ne polucheno processom-poluchatelem
SEND-blokirovan
Zapros Send(), i otpravlennoe im soobshchenie polucheno processom-poluchatelem, no otvet eshche ne vydan
REPLY-blokirovan
Zapros Receive(), no eshche ne poluchil soobshchenie
RECEIVE-blokirovan





Izmenenie sostoyaniya processov v tipichnom sluchae peredachi soobshcheniya.







Dlya polucheniya informacii obo vseh vozmozhnyh sostoyaniyah processa smotri
glavu "Menedzher processov".




Ispol'zovanie Send(), Receive() i Reply()
Davajte teper' bolee podrobno rassmotrim vyzovy funkcij Send(),
Receive() i Reply(). Vospol'zuemsya rassmotrennym vyshe
primerom peredachi soobshcheniya ot processa A k processu B.


Funkciya Send()
Predpolozhim, chto process A vydaet zapros na peredachu soobshcheniya
processu V. |to vypolnyaetsya posredstvom vyzova funkcii
Send():


Send( pid, smsg, rmsg, smsg_len, rmsg_len );


Pri vyzove funkcii Send() ispol'zuyutsya sleduyushchie argumenty:

pid
identifikator processa (process ID), kotoromu
prednaznachaetsya soobshchenie (t.e. processa B); etot identifikator
ispol'zuetsya dlya obrashcheniya k processu so storony operacionnoj
sistemy i drugih processov;
smsg
bufer soobshcheniya (t.e. soobshchenie, podlezhashchee posylke)
rmsg
bufer otveta (budet soderzhat' otvet ot processa B)
smsg_len
dlina posylaemogo soobshcheniya v bajtah
rmsg_len
maksimal'naya dlina otveta, kotoryj mozhet prinyat' process A, v bajtah

Obratite vnimanie, chto budet peredano ne bolee smsg_len bajt i
ne bolee chem rmsg_len bajt budet polucheno v kachestve otveta - eto
garantiruet, chto ne proizojdet sluchajnogo perepolneniya buferov.


Funkciya Receive()
Vyzvav zapros Receive(), process B mozhet poluchit' soobshchenie,
napravlennoe emu processom A:


pid = Receive( 0, msg, msg_len )


Vyzov funkcii Receive() soderzhit sleduyushchie argumenty:

pid
identifikator processa, kotoryj poslal soobshchenie (t.e. process A)
0
(nol') oznachaet, chto process B zhelaet prinyat' soobshchenie ot lyubogo
processa
msg
bufer, kuda budet pomeshcheno prinimaemoe soobshchenie
msg_len
maksimal'nyj razmer dannyh, kotorye budut pomeshcheny v bufer priema, v bajtah

Esli znacheniya argumentov smsg_len v vyzove funkcii Send()
i msg_len v vyzove funkcii Receive() otlichayutsya, drug ot
druga, to naimen'shee iz nih opredelyaet razmer dannyh, kotorye budut
peredany.


Funkciya Reply()
Posle uspeshnogo polucheniya soobshcheniya ot processa A, process B
dolzhen otvetit' processu A, vyzvav funkciyu Reply():


Reply( pid, reply, reply_len );


Vyzov funkcii Reply() soderzhit sleduyushchie argumenty:

pid
identifikator processa, kotoromu prednaznachaetsya otvet (t.e. process A)
reply
bufer, soderzhashchij otvet
reply_len
dlina dannyh, peredavaemyh v kachestve otveta, v bajtah

Esli znacheniya argumentov reply_len pri vyzove
funkcii Reply() i rmsg_len pri vyzove
funkcii Send() otlichayutsya drug ot druga, to
naimen'shee iz nih opredelyaet razmer peredavaemyh dannyh.


Reply-upravlyaemyj obmen soobshcheniyami
Primer obmena soobshcheniyami, kotoryj my tol'ko chto rassmotreli,
illyustriruet naibolee rasprostranennyj sluchaj ispol'zovaniya soobshchenij
- sluchaj, kogda dlya processa, vypolnyayushchego funkcii servera, normal'nym
yavlyaetsya sostoyanie RECEIVE-blokirovan v ozhidanii kakih-libo zaprosov
klienta.  |to nazyvaetsya send-upravlyaemyj obmen soobshcheniyami:
process-klient iniciiruet dejstvie, posylaya soobshcheniya, otvet servera na
soobshchenie zavershaet dejstvie.

Sushchestvuet i drugaya model' obmena soobshcheniyami, ne stol'
rasprostranennaya, kak rassmotrennaya vyshe, hotya v nekotoryh situaciyah
ona dazhe bolee predpochtitel'na: reply-upravlyaemyj obmen
soobshcheniyami, pri kotorom dejstvie iniciiruetsya vyzovom funkcii
Reply(). V etom sluchae process-"rabotnik" posylaet serveru
soobshchenie, govoryashchee o tom, chto on gotov k rabote. Server ne otvechaet
srazu, a "zapominaet", chto rabotnik gotov vypolnit' ego zadanie.
V posledstvii server mozhet iniciirovat' dejstvie, otvetiv ozhidayushchemu
zadanie rabotniku. Process-rabotnik vypolnit zadanie i zavershit
dejstvie, poslav serveru soobshchenie, soderzhashchee rezul'taty svoej raboty.


Dopolnitel'nye svedeniya
Pri razrabotke programm, ispol'zuyushchih peredachu soobshchenij,
neobhodimo imet' v vidu sleduyushchee:
soobshchenie sohranyaetsya v tele posylayushchego processa do teh por,
poka prinimayushchij process ne budet gotov poluchit' ego. Soobshchenie ne
kopiruetsya v Mikroyadro. |to bezopasno, t.k. posylayushchij process
SEND-blokirovan i ne mozhet neumyshlenno izmenit' soderzhimoe soobshcheniya

pri vyzove funkcii Reply() dannye kopiruyutsya
iz otvechayushchego processa v REPLY-blokirovannyj process kak odna nerazryvnaya
operaciya. Vyzov funkcii Reply() ne blokiruet
process - REPLY-blokirovannyj process perestaet byt' blokirovannym posle
togo, kak v nego skopirovany dannye;

pri posylke soobshcheniya processu ne trebuetsya znat' sostoyanie
togo processa, kotoromu eto soobshchenie adresovano. Esli poluchatel' ne
gotov k priemu soobshcheniya v moment ego otpravki, to posylayushchij soobshchenie
process prosto stanovitsya SEND-blokirovan;

esli eto neobhodimo, to process mozhet posylat' soobshchenie
nulevoj dliny, otvet nulevoj dliny, libo i to i drugoe;

s tochki zreniya razrabotchika, ispol'zovanie Send() dlya
peredachi processu-serveru zaprosa na poluchenie kakoj-libo uslugi
ravnoznachno vyzovu bibliotechnoj podprogrammy, predostavlyayushchej tu zhe
samuyu uslugu. V oboih sluchayah vasha programma snachala podgotavlivaet
opredelennye dannye, a zatem vyzyvaet libo funkciyu Send(), libo
bibliotechnuyu podprogrammu, posle chego ozhidaet, kogda oni zakonchat
vypolnenie. V oboih sluchayah kod, realizuyushchij zaprashivaemuyu uslugu,
vypolnyaetsya mezhdu dvumya chetko opredelennymi tochkami - Receive() i
Reply() dlya processa-servera, vhodom v podprogrammu i komandoj
return dlya vyzova bibliotechnoj podprogrammy. Kogda vyzyvaemaya
servisnaya programma zavershena, vasha programma "znaet", kuda pomeshcheny
rezul'taty, i mozhet pristupit' k proverke vozvrashchennogo koda oshibki,
obrabotke rezul'tatov i tak dalee.

Nesmotrya na takuyu kazhushchuyusya prostotu, vyzov funkcii Send()
delaet gorazdo bol'she, chem prostoj vyzov bibliotechnoj podprogrammy.
Funkciya Send() mozhet prozrachno dlya vyzyvayushchej programmy peredat'
zapros na drugoj uzel seti, gde i budet v dejstvitel'nosti vypolnyat'sya
obsluzhivayushchij zapros kod. Pri etom takzhe mozhet byt' zadejstvovana
parallel'naya obrabotka dannyh bez izderzhek na sozdanie novogo
processa. Process-server mozhet srazu, kak tol'ko stanet vozmozhnym,
vyzvat' funkciyu Reply(), pozvolyaya tem samym zaprashivavshemu processu
vozobnovit' vypolnenie i, v to zhe vremya, prodolzhit' vypolnenie samomu.

vozmozhna situaciya, kogda soobshcheniya ot mnogih processov
odnovremenno ozhidayut svoej obrabotki odnim i tem zhe prinimayushchim
processom. Kak pravilo, prinimayushchij process poluchaet soobshchenie v tom
zhe poryadke, v kakom oni byli poslany drugimi processami; odnako
prinimayushchij process mozhet ustanovit' ocherednost' polucheniya soobshchenij
na osnove prioritetov posylayushchih processov.





Server poluchil soobshchenie ot klienta A i klienta B (no eshche ne
otvetil im). Soobshcheniya ot klientov C, D, E eshche ne polucheny.




Dopolnitel'nye vozmozhnosti
QNX takzhe predostavlyaet sleduyushchie dopolnitel'nye vozmozhnosti po
peredache soobshchenij:

uslovnyj priem soobshchenij;
chtenie ili zapis' chasti soobshchenij;
sostavnye soobshcheniya (soobshcheniya, sostoyashchie iz neskol'kih chastej).

Uslovnyj priem soobshchenij
Obychno, kogda process hochet prinyat' soobshchenie, on vyzyvaet
funkciyu Receive() dlya ozhidaniya prihoda soobshcheniya. |to obychnyj
sposob polucheniya soobshchenij, kotoryj prigoden v bol'shinstve sluchaev.

Odnako vozmozhna situaciya, kogda processu neobhodimo opredelit',
imeyutsya li ozhidayushchie priema soobshcheniya, ne popadaya pri etom v sostoyanie
RECEIVE-blokirovan v sluchae ih otsutstviya. Naprimer, processu
trebuetsya oprashivat' rabotayushchee s vysokoj skorost'yu ustrojstvo,
kotoroe ne sposobno generirovat' preryvanie, i v to zhe vremya on dolzhen
otvechat' na soobshcheniya ot drugih processov. V etom sluchae process mozhet
ispol'zovat' funkciyu Creceive(), kotoraya libo prochitaet ozhidayushchee
priema soobshchenie, libo nemedlenno vernet upravlenie processu v sluchae
otsutstviya ozhidayushchih priema soobshchenij.





Sleduet po vozmozhnosti izbegat' ispol'zovaniya funkcii
Creceive(), t.k. ona pozvolyaet processu nepreryvno vypolnyat'sya
s neizmenyayushchimsya urovnem prioriteta.





CHtenie ili zapis' chasti soobshcheniya
Inogda zhelatel'no chitat' ili zapisyvat' soobshcheniya po chastyam s
tem, chtoby ispol'zovat' uzhe vydelennyj dlya soobshcheniya bufer vmesto
vydeleniya otdel'nogo rabochego bufera.

Naprimer, menedzher vvoda/vyvoda mozhet prinimat' dannye v vide
soobshchenij, kotorye sostoyat iz zagolovka fiksirovannoj dliny i
sleduyushchih za nim dannyh peremennoj dliny. V zagolovke ukazyvaetsya
razmer dannyh (ot 0 do 64 Kbajt). V etom sluchae menedzher
vvoda/vyvoda mozhet snachala prinyat' tol'ko zagolovok soobshcheniya, a zatem
ispol'zovat' funkciyu Readmsg() dlya chteniya dannyh peremennoj dliny
neposredstvenno v sootvetstvuyushchij bufer vyvoda. Esli razmer dannyh
prevyshaet razmer bufera, to menedzher mozhet neodnokratno vyzyvat'
funkciyu Readmsg() po mere osvobozhdeniya bufera vyvoda. Analogichnym
obrazom, funkciya Writemsg() mozhet byt' ispol'zovana dlya poetapnogo
kopirovaniya dannyh v vydelennyj dlya otvetnogo soobshcheniya bufer
neposredstvenno v tele processa, poslavshego soobshchenie, umen'shaya, takim
obrazom, potrebnost' menedzhera vvoda/vyvoda v vydelenii vnutrennih
buferov.


Sostavnye soobshcheniya
Do sih por my rassmatrivali soobshcheniya kak nepreryvnuyu
posledovatel'nost' bajt. Odnako soobshcheniya chasto sostoyat iz dvuh ili
bolee otdel'nyh chastej. Naprimer, soobshchenie mozhet imet' zagolovok
fiksirovannoj dliny, za kotorym sleduyut dannye peremennoj dliny. Dlya
togo chtoby izbezhat' kopirovaniya chastej takogo soobshcheniya vo vremennye
promezhutochnye bufery pri peredache ili prieme, mozhet byt' ispol'zovano
sostavnoe soobshchenie, sostoyashchee iz dvuh ili bolee otdel'nyh buferov
soobshchenij. Imenno blagodarya etoj vozmozhnosti menedzhery vvoda/vyvoda
QNX, takie kak Dev i Fsys, dostigayut svoej vysokoj
proizvoditel'nosti.

Sleduyushchie funkcii pozvolyayut obrabatyvat' sostavnye soobshcheniya:

Creceivemx()

Readmsgmx();
Receivemx();
Replymx();
Sendmx();
Writemsgmx().





Sostavnye soobshcheniya mogut byt' opisany s pomoshch'yuqqq�0 special'noj mx
struktury. Mikroyadro ob®edinyaet chasti takogo soobshcheniya v edinyj
nepreryvnyj potok dannyh.



Zarezervirovannye kody soobshchenij
QNX nachinaet vse soobshcheniya s 16-ti bitnogo slova, nazyvaemogo
kodom soobshcheniya. Zametim, odnako, chto eto ne yavlyaetsya
obyazatel'nym dlya vas trebovaniem pri napisanii sobstvennyh programm.
QNX ispol'zuet kody soobshchenij v sleduyushchih diapazonah:


Zarezervirovannyj diapazon:
Opisanie:
0x0000 - 0x00FF
Soobshcheniya Menedzhera processov
0x0100 - 0x01FF
Soobshcheniya vvoda/vyvoda (obshchie dlya vseh serverov vvoda/vyvoda)
0x0200 - 0x02FF
Soobshcheniya Menedzhera fajlovoj sistemy
0x0300 - 0x03FF
Soobshcheniya Menedzhera ustrojstv
0x0400 - 0x04FF
Soobshcheniya Menedzhera seti
0x0500 - 0x0FFF
Zarezervirovany dlya budushchih sistemnyh processov QNX



IPC posredstvom proksi
Proksi - eto forma neblokiruyushchego soobshcheniya, osobenno
podhodyashchego dlya izveshcheniya o nastuplenii sobytiya, kogda posylayushchij process
ne nuzhdaetsya v dialoge s poluchatelem. Edinstvennaya funkciya proksi sostoit
v posylke fiksirovannogo soobshcheniya opredelennomu processu, kotoryj
yavlyaetsya vladel'cem proksi.  Podobno soobshcheniyam, proksi mogut byt'
ispol'zovany v predelah vsej seti.

Ispol'zuya proksi, process ili obrabotchik preryvaniya mozhet poslat'
soobshchenie drugomu processu, ne blokiruyas' i ne ozhidaya otveta.

Vot nekotorye primery ispol'zovaniya proksi:

process zhelaet izvestit' drugoj process o nastuplenii
kakogo-libo sobytiya, no pri etom ne mozhet pozvolit' sebe posylku
soobshcheniya (v etom sluchae on ostavalsya by blokirovannym do teh
por, poka poluchatel' ne vyzovet Receive() i Reply());

process hochet poslat' dannye drugomu processu, no pri etom
emu ne trebuetsya ni otveta, ni kakogo-libo drugogo podtverzhdeniya togo,
chto adresat (poluchatel') poluchil soobshchenie;

obrabotchik preryvaniya hochet izvestit' process o postuplenii
novyh dannyh.


Dlya sozdaniya proksi ispol'zuetsya funkciya yazyka Si
qnx_proxy_attach(). Lyuboj drugoj process ili obrabotchik preryvaniya,
kotoromu izvesten identifikator proksi, mozhet vospol'zovat'sya funkciej
yazyka Si Trigger() dlya togo, chtoby zastavit' proksi peredat'
zaranee zadannoe soobshchenie. Zapros Trigger() obrabatyvaetsya
Mikroyadrom.

Proksi mozhet byt' "zapushcheno" neodnokratno - kazhdyj raz pri etom
ono posylaet soobshchenie. Proksi mozhet nakaplivat' ochered' dlinoj do
65535 soobshchenij.





Process-klient zapuskaet proksi 3 raza,  v rezul'tate chego server
poluchaet 3 "konservirovannyh" soobshcheniya ot proksi.




IPC posredstvom signalov
Signaly yavlyayutsya tradicionnym sposobom asinhronnoj svyazi, kotoraya
ispol'zuetsya v techenie mnogih let v razlichnyh operacionnyh sistemah.

QNX podderzhivaet bol'shoj nabor signalov, sootvetstvuyushchih standartu
POSIX, krome togo, signaly, istoricheski prisushchie nekotorym UNIX-sistemam,
i ryad signalov, unikal'nyh dlya QNX.


Kak porodit' signal
Schitaetsya, chto signal dostavlen processu togda, kogda vypolnyaetsya
opredelennoe v processe dlya dannogo signala dejstvie. Process mozhet
posylat' signal samomu sebe.


Esli vy hotite:
Ispol'zujte:
Porodit' signal iz komandnoj stroki
Utility: kill i slay
Porodit' signal vnutri processa
Funkcii Si: kill() i raise()

Poluchenie signalov
Process mozhet prinyat' signal odnim iz treh sposobov, v
zavisimosti ot togo, kak v processe opredelena obrabotka signalov:

esli process ne opredelil nikakih special'nyh mer po obrabotke
signala, to vypolnyaetsya predusmotrennoe dlya signala dejstvie po
umolchaniyu - obychno takim dejstviem po umolchaniyu yavlyaetsya zavershenie
raboty processa;

process mozhet ignorirovat' signal. Esli process ignoriruet
signal, to signal ne okazyvaet na process nikakogo vozdejstviya
(uchtite, chto SIGCONT, SIGSTOP i SIGKILL ne mogut byt' ignorirovany v
obychnyh obstoyatel'stvah);

process mozhet predusmotret' obrabotchik signala - funkciyu,
kotoraya budet vyzyvat'sya pri prieme signala. Esli process soderzhit
obrabotchik dlya kakogo-libo signala, govoryat, chto process mozhet
"pojmat'" etot signal. Lyuboj process, kotoryj "lovit" signal,
fakticheski poluchaet osobyj vid programmnogo preryvaniya. Nikakie dannye
s signalom ne peredayutsya.

V promezhutke vremeni mezhdu momentom, kogda signal
porozhden, i momentom, kogda on dostavlen, signal nazyvaetsya ozhidayushchim.
Dlya processa ozhidayushchimi odnovremenno mogut byt' neskol'ko razlichnyh
signalov. Signaly dostavlyayutsya processu, kogda planirovshchik yadra
delaet etot process gotovym k vypolneniyu. Process ne dolzhen stroit'
nikakih predpolozhenij otnositel'no poryadka, v kotorom budut
dostavleny ozhidayushchie signaly.


Perechen' signalov

Signal:
Opisanie:
SIGABRT
Signal nenormal'nogo zaversheniya, porozhdaetsya funkciej abort().
SIGALRM
Signal tajm-auta, porozhdaetsya funkciej alarm().
SIGBUS
Ukazyvaet na oshibku kontrolya chetnosti operativnoj pamyati (osobaya
dlya QNX interpretaciya). Esli vo vremya vypolneniya obrabotchika dannogo
signala proizojdet vtoraya takaya oshibka, to process budet zavershen.
SIGCHLD
Zavershenie porozhdennogo processa. Dejstvie po umolchaniyu - ignorirovat' signal.
SIGCONT
Esli process v sostoyanii HELD, to prodolzhit' vypolnenie.
Dejstvie po umolchaniyu - ignorirovat' signal, esli process ne v
sostoyanii HELD.
SIGDEV
Generiruetsya, kogda v Menedzhere ustrojstv proishodit vazhnoe i
zaproshennoe sobytie.
SIGFPE
Oshibochnaya arifmeticheskaya operaciya (celochislennaya ili s plavayushchej
zapyatoj), naprimer, delenie na nol' ili operaciya, vyzvavshaya
perepolnenie. Esli vo vremya vypolneniya obrabotchika dannogo signala
proizojdet vtoraya takaya oshibka, to process budet zavershen.
SIGHUP
Gibel' processa, kotoryj byl vedushchim seansa, ili zavisanie
upravlyayushchego terminala.
SIGILL
Obnaruzhenie nedopustimoj apparatnoj komandy. Esli vo vremya
vypolneniya obrabotchika dannogo signala proizojdet vtoraya takaya
oshibka, to process budet zavershen.
SIGINT
Interaktivnyj signal "vnimanie" (Break)
SIGKILL
Signal zaversheniya - dolzhen byt' ispol'zovan tol'ko v ekstrennyh
situaciyah. |tot signal ne mozhet byt' "pojman" ili ignorirovan.
Server mozhet zashchitit' sebya ot etogo signala posredstvom funkcii yazyka
Si qnx_pflags(). Dlya etogo server dolzhen imet' status
privilegirovannogo pol'zovatelya.
SIGPIPE
Popytka zapisi v programmnyj kanal, kotoryj ne otkryt dlya chteniya.
SIGPWR
Perezapusk komp'yutera v rezul'tate nazhatiya Ctrl-Alt-Shift-Del ili vyzova utility shutdown.
SIGQUIT
Interaktivnyj signal zaversheniya.
SIGSEGV
Obnaruzhenie nedopustimoj ssylki na operativnuyu pamyat'. Esli vo
vremya vypolneniya obrabotchika dannogo signala proizojdet vtoraya takaya
oshibka, to process budet zavershen.
SIGSTOP
Signal priostanovki vypolneniya (HOLD) processa. Dejstvie po
umolchaniyu - priostanovit' process. Server mozhet zashchitit' sebya ot
etogo signala posredstvom funkcii yazyka Si qnx_pflags().
Dlya etogo server dolzhen imet' status privilegirovannogo pol'zovatelya.
SIGTERM
Signal zaversheniya.
SIGTSTP
Ne podderzhivaetsya QNX.
SIGTTIN
Ne podderzhivaetsya QNX.
SIGTTOU
Ne podderzhivaetsya QNX.
SIGUSR1
Zarezervirovan kak opredelyaemyj prilozheniem signal 1.
SIGUSR2
Zarezervirovan kak opredelyaemyj prilozheniem signal 2.
SIGWINCH
Izmenilsya razmer okna.


Upravlenie obrabotkoj signalov
CHtoby zadat' zhelaemyj sposob obrabotki dlya kazhdogo  iz  signalov,
vy  mozhete  ispol'zovat'  funkcii yazyka Si signal() standarta
ANSI ili  sigaction() standarta POSIX.

Funkciya sigaction() predostavlyaet bol'shie vozmozhnosti po
upravleniyu obrabotkoj signalov.

Vy mozhete izmenit' sposob obrabotki signala v lyuboj moment
vremeni. Esli vy ukazhete, chto signal dannogo tipa dolzhen
ignorirovat'sya, to vse zhdushchie signaly takogo tipa budut nemedlenno
otbrosheny.


Obrabotchiki signalov
Nekotorye special'nye zamechaniya kasayutsya processov, kotorye lovyat
signaly posredstvom obrabotchikov signalov.

Vyzov obrabotchika signala analogichen programmnomu preryvaniyu. On
vypolnyaetsya asinhronno po otnosheniyu k ostal'noj chasti processa. Takim
obrazom, sushchestvuet veroyatnost' togo, chto obrabotchik signala budet
vyzvan vo vremya vypolneniya lyuboj iz imeyushchihsya v programme funkcij
(vklyuchaya bibliotechnye funkcii).

Esli v vashej programme ne predusmotren vozvrat iz obrabotchika
signala, to mogut byt' ispol'zovany funkcii siglongjmp() libo
longjmp() yazyka Si, odnako, funkciya siglongjmp()
predpochtitel'nee. Pri ispol'zovanii funkcii longjmp() signal
ostaetsya blokirovannym.


Blokirovanie signalov
Inogda mozhet vozniknut' neobhodimost' vremenno zapretit'
poluchenie signala, ne izmenyaya metod ego obrabotki. QNX predostavlyaet
nabor funkcij, kotorye pozvolyayut blokirovat' poluchenie signalov.
Blokirovannyj signal ostaetsya ozhidayushchim; posle razblokirovaniya on budet
dostavlen vashej programme.

Poka vasha programma vypolnyaet obrabotchik signala dlya
opredelennogo tipa signala, QNX avtomaticheski blokiruet etot signal.
|to oznachaet, chto net neobhodimosti zabotit'sya o vlozhennyh vyzovah
obrabotchika signala. Kazhdyj vyzov obrabotchika signala - eto nedelimaya
operaciya po otnosheniyu k dostavke sleduyushchih signalov etogo tipa.  Esli
vash process vypolnyaet normal'nyj vozvrat iz obrabotchika, signal
avtomaticheski razblokiruetsya.





Realizaciya obrabotchikov signalov v nekotoryh UNIX sistemah otlichaetsya
tem, chto pri poluchenii signalov oni ne blokiruyut ego, a ustanavlivayut
dejstvie po umolchaniyu. V rezul'tate nekotorye UNIX prilozheniya
vyzyvayut funkciyu signal() iznutri obrabotchika signalov, chtoby
podgotovit' obrabotchik k sleduyushchemu vyzovu. Takoj sposob imeet dva
nedostatka. Vo-pervyh, esli sleduyushchij signal postupaet, kogda vasha
programma uzhe vypolnyaet obrabotchik signala, no eshche ne vyzvala funkciyu
signal(), to programma mozhet byt' zavershena. Vo-vtoryh, esli signal
postupaet srazu posle vyzova funkcii signal() v obrabotchike, to
vozmozhen rekursivnyj vhod v obrabotchik signala. QNX podderzhivaet
blokirovanie signalov i, takim obrazom, ne stradaet ni ot odnogo iz etih
nedostatkov. Vam ne nuzhno vyzyvat' funkciyu signal() iznutri
obrabotchika signalov. Esli vy pokidaete obrabotchik cherez dal'nij
perehod (long jump), vam sleduet ispol'zovat' funkciyu siglongjmp().




Signaly i soobshcheniya
Sushchestvuet vazhnoe vzaimodejstvie mezhdu signalami i soobshcheniyami.
Esli vash process SEND-blokirovan ili RECEIVE-blokirovan v moment
polucheniya signala, i vy predusmotreli obrabotchik signala, proishodyat
sleduyushchie dejstviya:



 Process razblokiruetsya;
 Vypolnyaetsya obrabotka signala;
 Funkciya Send() ili Receive() vozvratit kod oshibki.


Esli process byl SEND-blokirovan v moment polucheniya signala, to
problemy ne voznikaet, potomu chto poluchatel' eshche ne poluchil soobshchenie.
No esli process byl RECEIVE-blokirovan, to vy ne uznaete, bylo li
obrabotano poslannoe im soobshchenie i, sledovatel'no, ne budete znat',
sleduet li povtoryat' Send().

Process, igrayushchij rol' servera (t.e. poluchayushchij soobshcheniya),
mozhet zaprosit', chtoby on poluchal izveshchenie vsyakij raz, kogda ego
process-klient poluchaet signal, nahodyas' v sostoyanii
REPLY-blokirovan. V etom sluchae klient stanovitsya SIGNAL-blokirovannym
s ozhidayushchim signalom. Server poluchaet special'nye soobshcheniya, opisyvayushchie
tip signala. Server mozhet zatem vybrat' odin iz sleduyushchih variantov:

zakonchit' vypolnenie zaprosa ot klienta normal'nym obrazom:
klient (process-otpravitel') budet uvedomlen, chto ego soobshchenie bylo
obrabotano dolzhnym obrazom

ILI
osvobodit' ispol'zuemye resursy i vozvratit' kod oshibki,
ukazyvayushchij, chto process byl razblokirovan signalom: klient poluchit
chetkij priznak oshibki.


Kogda server otvechaet processu, kotoryj byl SIGNAL-blokirovan,
to signal vydaetsya neposredstvenno posle vozvrata iz funkcii
Send(), vyzvannoj klientom (processom-otpravitelem).



IPC v seti

Virtual'nye kanaly
Prilozhenie v QNX mozhet obshchat'sya s processom na drugom komp'yutere
seti tochno tak zhe, kak esli by ono obshchalos' s drugim processom na tom
zhe samom komp'yutere. Kstati govorya, s tochki zreniya prilozheniya net
razlichiya mezhdu lokal'nym i udalennym resursom.

 Takaya zamechatel'naya stepen' prozrachnosti stanovitsya vozmozhna
blagodarya virtual'nym kanalam (ot anglijskogo virtual
circuit, sokrashchenno VC).  VC - eto puti, kotorye Menedzher seti
predostavlyaet dlya peredachi soobshchenij, proksi i signalov po seti.
VC sposobstvuyut effektivnomu ispol'zovaniyu QNX-seti v celom po
neskol'kim prichinam:



 Kogda sozdaetsya VC, on poluchaet vozmozhnost' obrabatyvat'
soobshcheniya vplot' do opredelennogo razmera; eto oznachaet, chto vy mozhete
predvaritel'no vydelit' resurs dlya obrabotki soobshcheniya.  Tem ne menee,
esli vam neobhodimo poslat' soobshchenie, prevyshayushchee zadannyj
maksimal'nyj razmer, VC avtomaticheski uvelichivaet razmer bufera.

 Esli dva processa, raspolagayushchiesya na razlichnyh uzlah seti,
ispol'zuyut dlya svyazi drug s drugom bolee chem odin VC, to takie VC
budut razdelyaemymi, tak kak mezhdu processami budet real'no
sushchestvovat' tol'ko odin virtual'nyj kanal. Takaya situaciya obychno
imeet mesto, kogda process ispol'zuet neskol'ko fajlov na udalennoj
fajlovoj sisteme.

 Esli process prisoedinyaetsya k sushchestvuyushchemu razdelyaemomu VC i
zaprashivaet bufer bol'shego razmera, chem tot, kotoryj ispol'zuetsya, to
razmer bufera avtomaticheski uvelichivaetsya.

 Kogda process zavershaet vypolnenie, vse svyazannye s nim VC
avtomaticheski osvobozhdayutsya.


Virtual'nye processy
Process-otpravitel' otvechaet za podgotovku VC mezhdu soboj i tem
processom, s kotorym on hochet ustanovit' svyaz'.  S etoj cel'yu
process-otpravitel' obychno vyzyvaet funkciyu qnx_vc_attach().
Krome sozdaniya VC, eta funkciya takzhe sozdaet na kazhdom konce kanala
virtual'nyj identifikator processa, sokrashchenno VID. Dlya kazhdogo iz processov,
VID na protivopolozhnom konce virtual'nogo kanala yavlyaetsya identifikatorom
udalennogo processa, s kotorym on ustanavlivaet svyaz'. Processy podderzhivayut
svyaz' drug s drugom posredstvom etih VID.

Naprimer, na sleduyushchem risunke virtual'nyj kanal soedinyaet PID
1 i PID 2.  Na uzle 20 - gde nahoditsya PID 1 - VID predstavlyaet PID 2.
Na uzle 40 - gde nahoditsya PID 2 - VID predstavlyaet PID 1. I PID 1 i
PID 2 mogut obrashchat'sya k VID na svoem uzle tak zhe, kak k lyubomu drugomu
lokal'nomu processu, posylaya soobshcheniya, prinimaya soobshcheniya, postavlyaya
signaly, ozhidaya i t.d. Tak, naprimer, PID 1 mozhet poslat' soobshchenie
VID na svoem konce, i etot VID peredast soobshchenie po seti k VID,
predstavlyayushchemu PID 1 na drugom konce. |tot VID zatem otpravit
soobshchenie k PID 2.





Svyaz' po seti realizuetsya posredstvom virtual'nyh kanalov.
Kogda PID 1 posylaet dannye VID 2, poslannyj zapros peredaetsya
po virtual'nomu kanalu, v rezul'tate VID 1 napravlyaet dannye PID 2.



Kazhdyj VID podderzhivaet soedinenie, kotoroe imeet sleduyushchie atributy:
 lokal'nyj pid;
 udalennyj pid;
 udalennyj nid (ID uzla);
 udalennyj vid.

Vozmozhno, vam ne pridetsya chasto imet' delo neposredstvenno s VC.
Tak, naprimer, kogda prilozhenie hochet poluchit' dostup k resursu
vvoda/vyvoda na drugom uzle seti, to VC sozdaetsya bibliotechnoj
funkciej open() ot imeni prilozheniya. Prilozhenie ne prinimaet
neposredstvennogo uchastiya v sozdanii ili ispol'zovanii VC. Analogichnym
obrazom, kogda prilozhenie opredelyaet mestonahozhdenie servera s pomoshch'yu
funkcii qnx_name_locate(), to VC avtomaticheski sozdaetsya ot imeni
prilozheniya. Dlya prilozheniya VC prosto yavlyaetsya PID servera.

Dlya bolee podrobnoj informacii o funkcii qnx_name_locate()
smotrite opisanie "Simvolicheskie imena
processov v glave "Menedzher processov".


Virtual'nye proksi
Virtual'noe proksi pozvolyaet posylat' proksi s udalennogo uzla,
podobno tomu, kak virtual'nyj kanal pozvolyaet processu obmenivat'sya
soobshcheniyami s udalennym uzlom.

V otlichie ot virtual'nogo kanala, kotoryj svyazyvaet vmeste dva
processa, virtual'nyj proksi mozhet byt' poslan lyubym processom na
udalennom uzle.

Virtual'nye proksi sozdayutsya funkciej qnx_proxy_rem_attach(),
kotoroj v kachestve argumentov peredayutsya uzel (nid_t) i proksi
(pid_t).





Na udalennom uzle sozdaetsya virtual'nyj proksi, kotoryj ssylaetsya
na lokal'nyj proksi.



Imejte v vidu, chto na vyzyvayushchem uzle virtual'nyj kanal  sozdaetsya
avtomaticheski posredstvom funkcii qnx_proxy_rem_attach().


Otklyuchenie virtual'nyh kanalov
Process mozhet utratit' vozmozhnost' svyazi po ustanovlennomu VC v
rezul'tate razlichnyh prichin:

 proizoshlo otklyuchenie pitaniya komp'yutera, na kotorom vypolnyalsya process;
 byl otsoedinen setevoj kabel' komp'yutera;
 udalennyj process, s kotorym byla ustanovlena svyaz', zavershil
vypolnenie.

Lyubaya iz etih prichin mozhet pomeshat' peredache soobshchenij po VC.
Neobhodimo vyyavlyat' takie situacii s tem, chtoby prilozheniya mogli
predprinyat' korrektiruyushchie dejstviya, libo korrektno zavershit' svoe
vypolnenie. Esli eto ne budet sdelano, to cennye resursy mogut
ostavat'sya bez neobhodimosti postoyanno zanyatymi.

Menedzher processov na kazhdom uzle proveryaet celostnost' VC na
svoem uzle. On delaet eto sleduyushchim obrazom:



 Kazhdyj raz, kogda proishodit uspeshnaya peredacha po VC,
obnovlyaetsya vremennaya metka, svyazannaya s dannym VC, v
sootvetstvii so vremenem poslednej operacii.

 CHerez opredelennye promezhutki vremeni Menedzher processov
proveryaet kazhdyj VC. Esli ne bylo zafiksirovano nikakih operacij, to
Menedzher processov posylaet proverochnyj paket Menedzheru processov na
drugom konce VC.

 Esli otvet ne poluchen ili vyyavlen sboj, to VC pomechaetsya kak
neispravnyj. Zatem delaetsya opredelennoe kolichestvo popytok
vosstanovit' soedinenie.

 Esli eti popytki ne dayut rezul'tata, to VC demontiruetsya; vse
processy, blokirovannye VC, perehodyat v sostoyanie READY (gotov).
Process poluchaet kod oshibki, vozvrashchaemoj ranee vyzvannoj funkciej
svyazi.


Dlya ustanovki parametrov, svyazannyh s dannoj proverkoj
celostnosti VC, ispol'zujte utilitu netpoll.



IPC posredstvom semaforov
Drugoj rasprostranennoj formoj sinhronizacii processov yavlyayutsya
semafory. Operacii "signalizacii" (sem_post()) i "ozhidaniya"
(sem_wait()) pozvolyayut upravlyat' vypolneniem processov,
perevodya ih v sostoyanie ozhidaniya libo vyvodya iz nego. Operaciya
signalizacii uvelichivaet znachenie semafora na edinicu, a operaciya
ozhidaniya umen'shaet ego na edinicu.

Pri polozhitel'nom znachenii semafora, pri vypolnenii operacii
ozhidaniya, process ne blokiruetsya. V protivnom sluchae operaciya ozhidaniya
blokiruet process do teh por, poka kakoj-libo drugoj process ne
vypolnit operaciyu signalizacii. Dopuskaetsya vypolnenie operacii
signalizacii odin ili bolee raz pered vypolneniem operacii ozhidaniya -
eto pozvolit odnomu ili neskol'kim processam vypolnit' operaciyu
ozhidaniya, ne blokiruyas'.

Vazhnoe otlichie mezhdu semaforami i drugimi primitivami
sinhronizacii zaklyuchaetsya v tom, chto semafory "asinhronno bezopasny" i
mogut ispol'zovat'sya obrabotchikami signalov. Esli trebuetsya, chtoby
obrabotchik signala vyvodil process iz sostoyaniya ozhidaniya, to semafory
yavlyayutsya pravil'nym vyborom.


Dispetcherizaciya processov

Kogda prinimayutsya resheniya po dispetcherizacii
Planirovshchik Mikroyadra prinimaet reshenie po dispetcherizacii:

 posle razblokirovki processa;
 po istechenii vremennogo intervala (kvanta) dlya vypolnyayushchegosya processa;
 kogda preryvaetsya tekushchij process.

Prioritety processov
V QNX kazhdomu iz processov prisvaivaetsya prioritet. Planirovshchik
vybiraet dlya vypolneniya sleduyushchij process, nahodyashchijsya v sostoyanii READY,
v sootvetstvii s ego prioritetom. (Programma v sostoyanii READY -
eto programma, kotoraya sposobna ispol'zovat' CP). Dlya vypolneniya vybiraetsya
process s naivysshim prioritetom.





V ocheredi shest' processov (A-F), gotovyh k vypolneniyu i
nahodyashchihsya v sostoyanii READY.  Ostal'nye processy (G-Z) blokirovany.
V dannyj moment vypolnyaetsya process A.  Processy A, B i C imeyut
naivysshij prioritet, poetomu budut razdelyat' central'nyj processor v
sootvetstvii s algoritmom dispetcherizacii dlya vypolnyaemogo processa.




Prioritety, prisvaivaemye processam, nahodyatsya v diapazone ot 0
(naimen'shij) do 31 (naivysshij).  Uroven' prioriteta po umolchaniyu dlya
sozdavaemogo processa nasleduetsya ot ego roditelya; dlya prilozhenij,
zapuskaemyh komandnym processorom, prioritet obychno raven 10.



Esli vy hotite:
Ispol'zujte funkciyu yazyka SI:
Opredelit' prioritet processa
getprio()
Ustanovit' prioritet dlya processa
setprio()

Metody dispetcherizacii
CHtoby udovletvorit' potrebnost' razlichnyh prilozhenij, QNX
predlagaet tri metoda dispetcherizacii:

FIFO;
karusel';
adaptivnyj.

Kazhdyj process v sisteme mozhet vypolnyat'sya, ispol'zuya lyuboj iz
etih metodov. Oni dejstvuyut primenitel'no k kazhdomu otdel'nomu
processu, a ne primenitel'no ko vsem processam na uzle.

Pomnite, chto eti metody dispetcherizacii primenimy, tol'ko kogda
dva ili bolee processa s odinakovym prioritetom nahodyatsya v sostoyanii
READY (t.e. eti processy neposredstvenno konkuriruyut drug s drugom).
Esli process s bolee vysokim prioritetom perehodit v sostoyanie READY,
to on nemedlenno vytesnyaet vse processy s bolee nizkim prioritetom.

Na sleduyushchej diagramme tri processa s odinakovym prioritetom
nahodyatsya v sostoyanii READY. Esli process A blokiruetsya, to
vypolnyaetsya process B.





Process A blokiruetsya, process B vypolnyaetsya.



Metod dispetcherizacii processa nasleduetsya ot ego roditel'skogo
processa, odnako, zatem etot metod mozhet byt' izmenen.


Esli vy hotite:
 Ispol'zujte funkciyu yazyka Si:

Opredelit' metod dispetcherizacii dlya processa
getscheduler()
Ustanovit' metod dispetcherizacii dlya processa
setscheduler()

FIFO dispetcherizaciya
Pri FIFO dispetcherizacii process prodolzhaet vypolnenie poka ne
nastupit moment, kogda on:

 dobrovol'no ustupaet upravlenie (t.e. vypolnyaet
lyuboj vyzov yadra);
 vytesnyaetsya processom s bolee vysokim prioritetom.




FIFO dispetcherizaciya. Process A vypolnyaetsya do teh por, poka ne blokiruetsya.



Dva processa, kotorye vypolnyayutsya s odnim i tem zhe prioritetom,
mogut ispol'zovat' metod FIFO dlya organizacii vzaimoisklyuchayushchego
dostupa k razdelyaemomu (t.e. sovmestno ispol'zuemomu) resursu. Ni odin
iz nih ne budet vytesnen drugim vo vremya svoego vypolneniya. Tak,
naprimer, esli oni sovmestno ispol'zuyut segment pamyati, to kazhdyj iz
etih dvuh processov mozhet obnovlyat' dannye v etom segmente, ne
pribegaya k ispol'zovaniyu kakogo-libo sposoba sinhronizacii (naprimer,
semafora).


Karusel'naya dispetcherizaciya
Pri karusel'noj dispetcherizacii process prodolzhaet vypolnenie,
poka ne nastupit moment, kogda on:

 dobrovol'no ustupaet upravlenie (t.e. blokiruetsya);
 vytesnyaetsya processom s bolee vysokim prioritetom;
 ispol'zoval svoj kvant vremeni (timeslice).




Karusel'naya dispetcherizaciya. Process A vypolnyaetsya do teh por,
poka on ne ispol'zoval svoj kvant vremeni; zatem vypolnyaetsya
sleduyushchij process, nahodyashchijsya v sostoyanii READY (process B).



Kvant vremeni - eto interval vremeni, vydelyaemyj kazhdomu processu.
Posle togo, kak process ispol'zoval svoj kvant vremeni, upravlenie
peredaetsya sleduyushchemu processu, kotoryj nahoditsya v sostoyanii READY i
imeet takoj zhe uroven' prioriteta.  Kvant vremeni raven 50
millisekundam.





 Za isklyucheniem kvantovaniya vremeni, karusel'naya dispetcherizaciya
identichna FIFO-dispetcherizacii.




Adaptivnaya dispetcherizaciya
Pri adaptivnoj dispetcherizacii process vedet sebya sleduyushchim obrazom:

Esli process ispol'zoval svoj kvant vremeni (t.e. on ne
blokirovalsya), to ego prioritet umen'shaetsya na 1.  |to poluchilo
nazvanie snizhenie prioriteta (priority decay). Uchtite, chto
"ponizhennyj" process ne budet prodolzhat' "snizhat'sya", dazhe esli on
ispol'zoval eshche odin kvant vremeni i ne blokirovalsya - on snizitsya
tol'ko na odin uroven' nizhe svoego ishodnogo prioriteta.

Esli process blokiruetsya, to emu vozvrashchaetsya pervonachal'noe
znachenie prioriteta.




Adaptivnaya dispetcherizaciya.  Process A ispol'zoval svoj kvant
vremeni; ego prioritet snizilsya na 1. Vypolnyaetsya sleduyushchij process v
sostoyanii READY (process B).



Vy mozhete ispol'zovat' adaptivnuyu dispetcherizaciyu v teh sluchayah,
kogda processy, proizvodyashchie intensivnye vychisleniya, vypolnyayutsya v
fonovom rezhime odnovremenno s interaktivnoj rabotoj pol'zovatelej. Vy
obnaruzhite, chto adaptivnaya dispetcherizaciya daet proizvodyashchim
intensivnye vychisleniya processam dostatochnyj dostup k CP i v to zhe
vremya sohranyaet bystryj interaktivnyj otklik dlya drugih processov.

Adaptivnaya dispetcherizaciya yavlyaetsya metodom dispetcherizacii,
ispol'zuyushchimsya po umolchaniyu dlya programm, zapuskaemyh komandnym
interpretatorom.


Klient-upravlyaemyj prioritet
V QNX obmen dannymi mezhdu processami v bol'shinstve sluchaev
organizovan s ispol'zovaniem modeli klient/server.
Servery vypolnyayut nekotorye servisnye funkcii, a klienty,
posylaya soobshchenie serveru, zaprashivayut eti uslugi. Kak pravilo, servery
bolee nadezhny i zhiznesposobny, chem klienty.

Kolichestvo klientov obychno bol'she, chem serverov. Kak sledstvie
etogo, prinyato zapuskat' server s prioritetom bolee vysokim, chem u
lyubogo iz ego klientov. Mozhet ispol'zovat'sya lyuboj iz treh
rassmotrennyh vyshe metodov dispetcherizacii, no, navernoe, samym
rasprostranennym yavlyaetsya karusel'nyj.

Esli klient s nizkim urovnem prioriteta posylaet soobshchenie
serveru, to ego zapros vypolnyaetsya pod bolee vysokim urovnem
prioriteta, tem, kotoryj imeetsya u servera.  |to kosvennym obrazom
povyshaet prioritet klienta, t.k. imenno ego zapros zastavil server
vypolnyat'sya.

Poka dlya vypolneniya zaprosa serveru dostatochno korotkogo
promezhutka vremeni, problem obychno ne voznikaet.  Esli zhe vypolnenie
zaprosa zanimaet u servera bolee prodolzhitel'noe vremya, to klient s
nizkim prioritetom mozhet neblagopriyatno povliyat' na vypolnenie drugih
processov, prioritety kotoryh vyshe, chem u klienta, no nizhe, chem u
servera.

CHtoby reshit' etu dilemmu, server mozhet postavit' svoj prioritet v
zavisimost' ot prioriteta togo klienta, chej zapros on vypolnyaet. Kogda
server poluchaet soobshchenie, prioritet budet ustanovlen takim zhe, kak u
klienta.  Obratite vnimanie, chto izmenilsya tol'ko prioritet servera -
ego algoritm dispetcherizacii ostaetsya neizmennym. Esli vo vremya
vypolneniya zaprosa server poluchaet drugoe soobshchenie, i prioritet
novogo klienta vyshe, chem u servera, to prioritet servera povyshaetsya.
Fakticheski, novyj klient "zaryazhaet" server do svoego urovnya
prioriteta, pozvolyaya emu zakonchit' vypolnenie tekushchego zaprosa i
pristupit' k obrabotke zaprosa novogo klienta.  Esli etogo ne delat',
to fakticheski prioritet novogo klienta ponizitsya, poka on blokirovan
na servere s nizkim prioritetom.

Esli vy vybrali klient-upravlyaemyj prioritet dlya svoego servera,
vam sleduet takzhe zaprosit' dostavku soobshchenij v poryadke ubyvaniya
prioritetov (v protivopolozhnost' hronologicheskomu).

CHtoby ustanovit' klient-upravlyaemyj prioritet, ispol'zujte
funkciyu Si qnx_pflags() sleduyushchim obrazom:


qnx_pflags(~0, _PPF_PRIORITY_FLOAT
            | _PPF_PRIORITY_REC, 0, 0);



Neskol'ko slov o real'nom vremeni
Kak by my etogo ne hoteli, komp'yutery ne yavlyayutsya beskonechno
bystrymi.  Dlya sistemy real'nogo vremeni zhiznenno vazhno, chtoby takty
raboty CP ne rashodovalis' zrya. Takzhe ochen' vazhno svesti k minimumu
vremya, kotoroe prohodit s momenta nastupleniya vneshnego sobytiya do
nachala vypolneniya koda programmy, otvetstvennoj za obrabotku dannogo
sobytiya. |to vremya nazyvaetsya zaderzhkoj.

V QNX sisteme vstrechaetsya neskol'ko vidov zaderzhek.

Zaderzhka preryvaniya
Zaderzhka preryvaniya - eto interval vremeni mezhdu apparatnym
preryvaniem i vypolneniem pervoj komandy programmnogo obrabotchika
preryvaniya. QNX prakticheski vse vremya ostavlyaet preryvaniya polnost'yu
razreshennymi, poetomu zaderzhka preryvaniya, kak pravilo, ne sushchestvenna.
Odnako nekotorye kriticheskie fragmenty koda trebuyut, chtoby preryvaniya
byli vremenno zapreshcheny. Maksimal'naya prodolzhitel'nost' takogo zapreta
obychno opredelyaet hudshij sluchaj zaderzhki preryvaniya - v QNX eto ochen'
nebol'shaya velichina.

Sleduyushchaya diagramma illyustriruet sluchaj, kogda apparatnoe
preryvanie obrabatyvaetsya v ustanovlennom obrabotchikom preryvanii.
Obrabotchik preryvaniya libo prosto vypolnit komandu vozvrata, libo pri
vozvrate zapustit proksi.





Obrabotchik preryvaniya prosto zavershaetsya.




Zaderzhka preryvaniya (Til) na privedennoj vyshe diagramme otrazhaet
minimal'nuyu zaderzhku - sluchaj, kogda preryvaniya byli polnost'yu
razresheny v moment, kogda proizoshlo preryvanie. V hudshem sluchae zaderzhka
preryvaniya sostavit eto vremya plyus naibol'shee vremya, v techenie
kotorogo QNX ili vypolnyayushchijsya process zapreshchaet preryvaniya CP.


Til dlya razlichnyh processorov
Sleduyushchaya tablica soderzhit tipichnye znacheniya zaderzhki preryvaniya
(Tqqq�1ilqqq�0) dlya raznyh processorov:


Zaderzhka preryvaniya (Til):
Processor:
3.3 mikrosekundy
166 MGc Pentium
4.4 mikrosekundy
100 MGc Pentium
5.6 mikrosekundy
100 MGc 486DX4
22.5 mikrosekundy
33 MGc 386EX

Zaderzhka dispetcherizacii
V nekotoryh sluchayah obrabotchik apparatnogo preryvaniya nizkogo
urovnya dolzhen peredat' upravlenie processu bolee vysokogo urovnya. V
etom sluchae obrabotchik preryvaniya pered vypolneniem komandy "vozvrat"
zapuskaet proksi. Zdes' imeet mesto vtoroj vid zaderzhki - zaderzhka
dispetcherizacii, - s kotoroj takzhe nado schitat'sya.

Zaderzhka dispetcherizacii - eto vremya mezhdu zaversheniem raboty
obrabotchika preryvaniya i vypolneniem pervoj komandy processa-drajvera.
|to vremya, neobhodimoe dlya sohraneniya konteksta, vypolnyayushchegosya v
dannyj moment vremeni processa, i vosstanovleniya konteksta trebuemogo
drajvera. V QNX eto vremya takzhe neveliko, hotya i bol'she zaderzhki
preryvaniya.





Obrabotchik preryvaniya zavershaet rabotu i zapuskaet proksi.



Vazhno otmetit', chto obrabotka bol'shinstva preryvanij zavershaetsya
bez zapuska proksi.  V bol'shinstve sluchaev obrabotchik preryvaniya sam
mozhet vypolnit' vse neobhodimye dejstviya. Zapusk proksi, chtoby "razbudit'"
drajver, process bolee vysokogo urovnya, proishodit tol'ko
pri nastuplenii vazhnogo sobytiya. Naprimer, obrabotchik preryvaniya dlya
drajvera posledovatel'nogo porta pri kazhdom preryvanii "registr peredachi
svoboden" budet peredavat' odin bajt dannyh i zapustit process bolee
vysokogo urovnya (Dev) tol'ko togda, kogda vyhodnoj bufer, nakonec,
opusteet.


Tsl dlya razlichnyh processorov
Sleduyushchaya tablica soderzhit tipichnye znacheniya zaderzhki
dispetcherizacii (Tsl) dlya raznyh processorov:


Zaderzhka dispetcherizacii (Tsl):
Processor:
4.7 mikrosekundy
166 MGc Pentium

6.7 mikrosekundy
100 MGc Pentium
11.1 mikrosekundy
100 MGc 486DX4
74.2 mikrosekundy
33 MGc 386EX

Stek preryvanij
Tak kak arhitektura mikrokomp'yuterov pozvolyaet naznachat'
prioritety apparatnym preryvaniyam, to preryvaniya s bolee vysokim
prioritetom mogut vytesnyat' preryvaniya s men'shim prioritetom.

|tot mehanizm polnost'yu podderzhivaetsya v QNX. Vyshe byli
rassmotreny prostejshie - i naibolee tipichnye - situacii, kogda
proishodit tol'ko odno preryvanie. Prakticheski takoj zhe raschet vremeni
spravedliv dlya preryvaniya s naivysshim prioritetom. Pri rassmotrenii
naihudshego sluchaya dlya preryvaniya s nizkim prioritetom neobhodimo
uchityvat' vremya obrabotki vseh preryvanij bolee vysokogo urovnya, t.k.
v QNX preryvanie s bolee vysokim prioritetom vytesnit preryvanie s
men'shim prioritetom.





Vypolnyaetsya process A.  Preryvanie IRQx vyzyvaet vypolnenie
obrabotchika preryvaniya Intx, kotoryj vytesnyaetsya IRQy
i ego obrabotchikom Inty.  Inty zapuskaet proksi,
vyzyvayushchee vypolnenie processa B, a Intx zapuskaet proksi,
vyzyvayushchee vypolnenie processa C.










Menedzher processov

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
zhiznennyj cikl processa;
sostoyaniya processa;
simvol'nye imena processov;
tajmery;
obrabotchiki preryvanij.


Vvedenie

Obyazannosti Menedzhera processov
Menedzher processov tesno vzaimodejstvuet s Mikroyadrom, chtoby
obespechit' uslugi, sostavlyayushchie sushchnost' operacionnoj sistemy. Hotya
on i yavlyaetsya edinstvennym processom, kotoryj ispol'zuet to zhe
adresnoe prostranstvo, chto i Mikroyadro, Menedzher processov vypolnyaetsya
kak istinnyj process. I on, kak i vse ostal'nye processy, podvergaetsya
dispetcherizacii so storony YAdra i ispol'zuet predostavlyaemye
Mikroyadrom primitivy peredachi soobshchenij dlya svyazi s drugimi processami
v sisteme.

Menedzher processov otvechaet za sozdanie novyh processov v sisteme
i za upravlenie osnovnymi resursami, svyazannymi s processom. Vse eti
uslugi predostavlyayutsya posredstvom soobshchenij. Tak, naprimer, esli
process hochet porodit' novyj process, on delaet eto, posylaya soobshchenie
s ukazaniem atributov sozdavaemogo processa.  Obratite vnimanie, chto
t.k. soobshcheniya peredayutsya po seti, vy mozhete legko sozdat' process na
drugom uzle seti, poslav soobshchenie Menedzheru processov na etom uzle.


Primitivy sozdaniya processov
QNX podderzhivayut tri primitiva sozdaniya processa:

fork();
exec();
spawn().
Primitivy fork() i exec() opredeleny standartom POSIX,
a primitiv spawn() realizovan tol'ko v QNX.

Primitiv fork()
Primitiv fork() sozdaet novyj process, kotoryj yavlyaetsya tochnoj
kopiej vyzvavshego ego processa. Novyj process ispol'zuet tot zhe samyj
kod, chto i porodivshij ego process, i nasleduet kopiyu vseh dannyh
roditel'skogo processa.


Primitiv exec()
Primitiv exec() zamenyaet vyzvavshij process novym. Posle uspeshnogo
vyzova exec() vozvrata ne proishodit, t.k. obraz vyzyvayushchego processa
zamenyaetsya obrazom novogo processa. Obychnoj praktikoj v POSIX-sistemah dlya
sozdaniya novogo processa - bez udaleniya vyzyvayushchego processa - yavlyaetsya snachala
vyzov fork(), a zatem vyzov exec() iz porozhdennogo processa.


Primitiv spawn()
Primitiv spawn() sozdaet novyj process kak potomok vyzyvayushchego
processa.  S ego pomoshch'yu mozhno izbezhat' vyzovov fork() i
exec(), ispol'zuya bolee bystryj i effektivnyj sposob sozdaniya novyh
processov. V otlichie ot fork() i exec(), kotorye po svoej
prirode vypolnyayutsya na tom zhe samom uzle, chto i vyzyvayushchij process,
primitiv spawn() mozhet sozdavat' processy na lyubom uzle
seti.


Nasledovanie
Kogda s pomoshch'yu odnogo iz treh rassmotrennyh vyshe primitivov
zadaetsya novyj process, on nasleduet mnogoe iz svoego okruzheniya ot
roditelya. |to svedeno v sleduyushchuyu tablicu:


Nasleduemyj parametr
fork()
exec()
spawn()
Identifikator processa
net
da
net
Otkrytye fajly
da
po vyboru*
po vyboru
Blokirovka fajlov
net
da
net
Ozhidayushchie signaly
net
da
net
Maska signalov
da
po vyboru
po vyboru
Ignoriruemye signaly
da
po vyboru
po vyboru
Obrabotchiki signalov
da
net
net
Peremennye okruzheniya
da
po vyboru
po vyboru
Identifikator seansa
da
da
po vyboru
Gruppa processa
da
da
po vyboru
Real'nye UID, GID
da
da
da
|ffektivnye UID, GID
da
po vyboru
po vyboru
Tekushchij rabochij katalog
da
po vyboru
po vyboru
Maska sozdaniya fajlov
da
da
da
Prioritet
da
po vyboru
po vyboru
Algoritm dispetcherizacii
da
po vyboru
po vyboru
Virtual'nye kanaly
net
net
net
Simvol'nye imena
net
net
net
tajmery real'nogo vremeni
net
net
net
*po vyboru: vyzyvayushchij process mozhet po neobhodimosti vybrat' -
da ili net.



ZHiznennyj cikl processa
Process prohodit cherez chetyre stadii:



Sozdanie.
Zagruzka.
Vypolnenie.
Zavershenie.


Sozdanie
Sozdanie novogo processa sostoit iz prisvoeniya novomu processu
identifikatora (ID) processa i podgotovki informacii, kotoraya
opredelyaet okruzhenie novogo processa.  Bol'shaya chast' etoj
informacii nasleduetsya ot roditel'skogo processa (smotri razdel
"Nasledovanie").


Zagruzka
Zagruzka obraza processa proizvoditsya nit'yu zagruzchika.
Kod zagruzchika nahoditsya v Menedzhere processov, no nit' vypolnyaetsya pod ID
novogo processa. |to pozvolyaet Menedzheru processov obrabatyvat' i drugie
zaprosy vo vremya zagruzki programmy.


Vypolnenie

Posle togo, kak kod programmy zagruzhen, process gotov k
vypolneniyu; on nachinaet konkurirovat' s ostal'nymi processami za
resursy CP. Zamet'te, chto vse processy vypolnyayutsya parallel'no so
svoimi roditelyami. Krome togo, smert' roditel'skogo processa ne
oznachaet avtomaticheskuyu smert' ego dochernih processov.


Zavershenie
Process zavershaetsya odnim iz dvuh sposobov:

process poluchaet signal, kotoryj vyzyvaet zavershenie processa;

process vyzyvaet funkciyu Si exit(), libo v yavnom vide,
libo v kachestve dejstviya po umolchaniyu pri vozvrate iz funkcii main().


Zavershenie vklyuchaet dve stadii:


Vypolnyaetsya nit' zaversheniya v Menedzhere processov. |tot
"zasluzhivayushchij doveriya" kod raspolozhen v Menedzhere processov, no nit'
vypolnyaetsya s ID zavershayushchegosya processa. |ta nit' zakryvaet vse
otkrytye fajlovye deskriptory i osvobozhdaet sleduyushchie resursy:

 vse virtual'nye kanaly, prinadlezhashchie processu;
 vsyu pamyat', vydelennuyu processu;
 vse simvol'nye imena;
 lyubye starshie nomera ustrojstv (tol'ko menedzhery vvoda/vyvoda);
 lyubye obrabotchiki preryvaniya;
 lyubye proksi;
 lyubye tajmery.
Posle togo, kak nit' zaversheniya vypolnena, izveshchenie o
zavershenii processa posylaetsya roditel'skomu processu (eta faza
vypolnyaetsya vnutri Menedzhera processov).

Esli roditel'skij process ne vyzval wait() ili
waitpid(), to dochernij process stanovitsya "zombi" i ne budet
zavershen, poka roditel'skij process ne vyzovet wait() ili ne
zavershit vypolnenie. (Esli vy ne hotite, chtoby process zhdal smerti
dochernih processov, vy dolzhny libo ustanovit' _SPAWN_NOZOMBIE flag
funkciyami qnx_spawn() ili qnx_spawn_options(), libo ustanovit'
dejstvie SIG_IGN dlya signala SIGCHLD posredstvom funkcii signal().
Takim obrazom, dochernie processy ne budut stanovit'sya zombi posle
smerti.)

Roditel'skij process mozhet zhdat' smerti dochernego processa,
zapushchennogo na udalennom uzle. Esli roditel' processa-zombi umiraet,
to zombi osvobozhdaetsya.

Esli zapushchena utilita dumper i process zavershaetsya v
rezul'tate polucheniya signala, to generiruetsya damp pamyati. Vy mozhete
zatem issledovat' ego s pomoshch'yu otladchika.



Sostoyaniya processa
Process vsegda nahoditsya v odnom iz sleduyushchih sostoyanij:

READY (gotov) - process sposoben ispol'zovat' CP (t.e. on ne
zhdet nastupleniya kakogo-libo sobytiya).

BLOCKED (blokirovan) - process v odnom iz sleduyushchih blokirovannyh
sostoyanij:

  
SEND-blokirovan;


  
RECEIVE-blokirovan;


  
REPLY-blokirovan;


  
SIGNAL-blokirovan;


  
SEMAPHORE-blokirovan.



HELD (priostanovlen) - process poluchil signal SIGSTOP.
V etom sostoyanii process ne imeet prava ispol'zovat' CP; vyjti
iz sostoyaniya HELD process mozhet tol'ko v rezul'tate polucheniya
signala SIGCONT, ili zavershiv svoyu rabotu posle polucheniya drugogo signala.

WAIT (blokirovan) - process vypolnil vyzov funkcii wait()
ili waitpid() dlya ozhidaniya soobshcheniya o zavershenii vypolneniya
dochernego processa.

DEAD (mertv) - process zavershil vypolnenie, no ne mozhet poslat'
soobshcheniya ob etom roditel'skomu processu, t.k. roditel'skij process ne
vyzval wait() ili waitpid(). Kogda process nahoditsya v
sostoyanii DEAD, ranee zanimaemaya im pamyat' uzhe osvobozhdena. Process v
sostoyanii DEAD takzhe nazyvayut zombi.





Dlya polucheniya bolee polnoj informacii o blokirovannom sostoyanii
obratites' k glave "Mikroyadro".







Vozmozhnye sostoyaniya processa v QNX.



Pokazany sleduyushchie perehody:


Process posylaet soobshchenie.
Process-adresat poluchaet soobshchenie.
Process-adresat otvechaet na soobshchenie.
Process ozhidaet soobshcheniya.
Process poluchaet soobshchenie.
Signal razblokiruet process.
Signal pytaetsya razblokirovat' process; adresat ranee zaprosil
izveshchenie o signale putem posylki soobshcheniya.
Process-adresat poluchaet soobshchenie o signale.
Process ozhidaet smerti dochernego processa.
Dochernij process umiraet, libo signal razblokiruet process.
Process poluchaet SIGSTOP.
Process poluchaet SIGCONT.
Process umiraet.
Roditel'skij process vyzyvaet funkciyu wait() ili
waitpid(), zavershaet ee vypolnenie, libo ranee uzhe zavershil vypolnenie.
Process vyzyvaet funkciyu semwait() dlya semafora s
nepolozhitel'nym znacheniem.
Drugoj process vyzyvaet funkciyu sempost(), ili prihodit
nemaskirovannyj signal.


Opredelenie sostoyanij processa
CHtoby opredelit' sostoyanie konkretnogo processa iz komandnogo
interpretatora (Shell), ispol'zujte utility ps i sin
(vnutri prilozhenij ispol'zujte funkciyu qnx_psinfo()).

CHtoby opredelit' sostoyanie operacionnoj sistemy v celom iz
komandnogo interpretatora (Shell), ispol'zujte utilitu sin (vnutri
prilozhenij ispol'zujte funkciyu qnx_osinfo()).

Utilita ps opredelena standartom POSIX; ee ispol'zovanie v
komandnyh fajlah mozhet byt' perenosimym v drugie sistemy. Utilita
sin, naprotiv, unikal'na dlya QNX; ona daet vam poleznuyu informaciyu,
specificheskuyu dlya QNX, kotoruyu vy ne mozhete poluchit', ispol'zuya
utilitu ps.



Simvol'nye imena processov
QNX stimuliruet razrabotku prilozhenij, kotorye razbity na
neskol'ko vzaimodejstvuyushchih processov. Takoe prilozhenie, kotoroe
sushchestvuet kak gruppa vzaimodejstvuyushchih processov, imeet bol'shie
vozmozhnosti rasparallelivaniya i mozhet byt' raspredeleno po seti dlya
luchshej proizvoditel'nosti.

Odnako razdelenie prilozhenij na vzaimodejstvuyushchie processy
trebuet ryada special'nyh soobrazhenij. CHtoby vzaimodejstvuyushchie processy
mogli ustanovit' svyaz' mezhdu soboj, oni dolzhny imet' vozmozhnost'
opredelit' identifikatory drug druga. Naprimer, dopustim, chto imeetsya
server bazy dannyh, kotoryj mozhet obsluzhivat' proizvol'noe kolichestvo
klientov. Klienty mogut zapuskat'sya i prekrashchat' rabotu v lyuboe vremya,
odnako server vsegda ostaetsya dostupnym. Kak processy-klienty uznayut
identifikator processa-servera bazy dannyh s tem, chtoby poslat' emu
soobshchenie?

V QNX processy mogut prisvaivat' sebe simvol'nye imena.  V
kontekste odnogo uzla processa mogut zaregistrirovat' eti imena u
Menedzhera processov na tom uzle, na kotorom oni vypolnyayutsya. Ostal'nye
processy mogut zatem zaprosit' u Menedzhera processov identifikator
processa, associirovannyj s opredelennym imenem.

Situaciya stanovitsya bolee slozhnoj, esli my rassmotrim set', v
kotoroj server obsluzhivaet klientov, nahodyashchihsya na razlichnyh uzlah.
Poetomu v QNX predusmotrena podderzhka kak global'nyh, tak i lokal'nyh
imen. Global'nye imena opredeleny dlya vsej seti, v to vremya kak
lokal'nye imena opredeleny tol'ko dlya togo uzla, na kotorom oni
zaregistrirovany. Global'nye imena nachinayutsya s kosoj cherty
(/). Naprimer:


qnx/fsys
lokal'noe imya
company/xyz
lokal'noe imya
/company/xyz
global'noe imya




My rekomenduem  vam  ispol'zovat'  nazvanie  vashej kompanii v kachestve
prefiksa dlya vseh registriruemyh imen, chtoby izbezhat' konfliktov imen
mezhdu programmami raznyh proizvoditelej.




CHtoby sdelat' vozmozhnym ispol'zovanie global'nyh imen,
hotya by na odnom uzle seti dolzhen byt' zapushchen process,
izvestnyj kak opredelitel' imen (utilita nameloc).
|tot process vedet uchet vseh zaregistrirovannyh global'nyh imen.

V kazhdyj moment vremeni v seti mogut byt' zapushcheny do desyati
opredelitelej imen.  Kazhdyj hranit identichnye kopii vseh aktivnyh
global'nyh imen.  Takaya izbytochnost' garantiruet normal'noe
funkcionirovanie seti, dazhe esli odin ili neskol'ko uzlov,
obespechivayushchih opredelenie imen, vyjdut iz stroya odnovremenno.

CHtoby zaregistrirovat' imya, process server ispol'zuet
funkciyu Si qnx_name_attach(). CHtoby opredelit' process po imeni,
process klient ispol'zuet funkciyu Si qnx_name_locate().



Tajmery

Ischislenie vremeni
V QNX ischislenie vremeni osnovyvaetsya na sistemnom tajmere,
podderzhivaemom operacionnoj sistemoj. Tajmer soderzhit tekushchee znachenie
Koordinirovannogo Vsemirnogo Vremeni (UTC) otnositel'no 0 chasov, 0
minut, 0 sekund, 1 yanvarya 1970 goda. CHtoby opredelit' mestnoe vremya,
funkcii ischisleniya vremeni ispol'zuyut peremennuyu okruzheniya TZ
(kotoraya opisyvaetsya v knige Rukovodstvo pol'zovatelya).


Prostye sredstva otscheta vremeni
Komandnye fajly i processy mogut delat' pauzu na opredelennoe
kolichestvo sekund, ispol'zuya prostye sredstva otscheta vremeni.  V
komandnyh fajlah dlya etoj celi ispol'zuetsya utilita sleep; v
processah ispol'zuetsya funkciya Si sleep(). Takzhe mozhet
ispol'zovat'sya funkciya delay(), kotoroj v kachestve argumenta
peredaetsya dlina intervala vremeni v millisekundah.


Bolee slozhnoe sredstvo otscheta vremeni
Krome togo, process mozhet sozdavat' tajmery, ustanavlivat' ih na
opredelennyj interval vremeni i udalyat' tajmer.  |ti sredstva otscheta
vremeni osnovyvayutsya na specifikacii POSIX Std 1003.4/Draft 9.


Sozdanie tajmerov
Process mozhet sozdat' odin ili bol'she tajmerov. |ti tajmery mogut
byt' lyubyh tipov i v lyubom sochetanii. S uchetom konfiguriruemogo
ogranicheniya obshchego chisla tajmerov, podderzhivaemyh operacionnoj
sistemoj (smotri Proc v Opisanie utilit).
Dlya sozdaniya tajmera ispol'zujte funkciyu timer_create().


Ustanovka tajmerov
Pri ustanovke tajmerov vy mozhete ispol'zovat' odin iz dvuh tipov
intervalov vremeni:

absolyutnyj - vremya otnositel'no 0 chasov, 0 minut,
0 sekund, 1 yanvarya 1970 goda;
otnositel'nyj - vremya otnositel'no tekushchego pokazaniya chasov.
Vy takzhe mozhete sozdat' tajmer, periodicheski srabatyvayushchij s
zadannym intervalom vremeni. Naprimer, vy ustanovili tajmer takim
obrazom, chtoby on srabotal zavtra v 9 chasov utra. Vy mozhete zadat',
chtoby posle etogo on srabatyval kazhdye 5 minut.

Vy takzhe mozhete ustanovit' vremennoj interval dlya sushchestvuyushchego
tajmera. Rezul'tat budet zaviset' ot tipa intervala vremeni:

 dlya absolyutnogo tajmera novyj interval zamenyaet tekushchij
interval vremeni;
 dlya otnositel'nogo tajmera novyj interval dobavlyaetsya k
lyubomu ostayushchemusya intervalu vremeni.


CHtoby ustanovit' tajmer:
Ispol'zujte funkciyu:
Absolyutnyj ili otnositel'nyj interval
timer_settime()

Udalenie tajmerov
CHtoby udalit' tajmer, ispol'zujte funkciyu Si timer_delete().


Ustanovka razresheniya tajmera
Vy mozhete ustanovit' razreshenie dlya tajmera s pomoshch'yu utility
ticksize ili funkcii qnx_timerperiod(). Vy mozhete
nastraivat' razreshenie ot 500 mikrosekund do 50 millisekund.


CHtenie tajmera
CHtoby uznat' ostavshijsya ot tajmera interval ili proverit', ne byl
li tajmer udalen, ispol'zujte funkciyu Si timer_gettime().



Obrabotchiki preryvanij
Obrabotchiki preryvanij obsluzhivayut sistemu apparatnyh preryvanij
komp'yutera - oni reagiruyut na apparatnye preryvaniya i osushchestvlyayut
peredachu dannyh mezhdu komp'yuterom i vneshnimi ustrojstvami na nizkom
urovne.

Obrabotchiki preryvanij fizicheski yavlyayutsya chast'yu standartnogo
processa QNX (naprimer, drajver), no oni vsegda vypolnyayutsya asinhronno
po otnosheniyu k processu, v kotoryj oni vklyucheny.

Obrabotchik preryvanij:
poluchaet upravlenie posredstvom dal'nego vyzova, a ne
neposredstvenno ot preryvaniya (eto mozhet byt' napisano na Si, a ne na
assemblere);
vypolnyaetsya v kontekste process, v kotoryj on vklyuchen, takim
obrazom imeet dostup ko vsem global'nym peremenam etogo processa;
vypolnyaetsya pri razreshennyh preryvaniyah, no vytesnyaetsya tol'ko
v sluchae, esli proishodit preryvanie s bolee vysokim prioritetom;
ne dolzhen neposredstvenno upravlyat' kontrollerom preryvaniya
8259 (ob etom zabotitsya operacionnaya sistema);
dolzhen byt' kak mozhno koroche.


Neskol'ko processov mogut obrabatyvat' odno i to zhe preryvanie
(esli eto podderzhivaetsya apparatno). Kogda proishodit fizicheskoe
preryvanie, vse obrabotchiki preryvanij budut po ocheredi poluchat'
upravlenie.  Ne dolzhno delat'sya nikakih predpolozhenij otnositel'no
poryadka, v kotorom budut vyzyvat'sya obrabotchiki preryvanij,
razdelyayushchie odno i to zhe preryvanie.


Esli vy hotite:
Ispol'zujte funkciyu:
Ustanovit' obrabotchik preryvaniya
qnx_hint_attach()
Udalit' obrabotchik preryvaniya
qnx_hint_detach()

Obrabotchiki preryvaniya tajmera
Vy mozhete ustanovit' obrabotchik preryvaniya neposredstvenno dlya
sistemnogo tajmera takim obrazom, chto obrabotchik budet vyzyvat'sya po
kazhdomu preryvaniyu tajmera. CHtoby ustanovit' period, vy mozhete
ispol'zovat' utilitu ticksize.

Vy mozhete takzhe ustanovit' obrabotchik preryvaniya dlya
otmasshtabirovannogo preryvaniya tajmera, kotoroe budet proishodit'
kazhdye 50 millisekund, nezavisimo ot tick size. |ti tajmery
predlagayut nizkourovnevuyu al'ternativu POSIX 1003.4 tajmeram.









Prostranstvo imen vvoda/vyvoda

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
razbor imen fajlov;
prostranstvo deskriptorov fajlov.



Vvedenie

Prostranstvo imen vvoda/vyvoda
Resursy vvoda/vyvoda (I/O, ot anglijskogo Input/Output) v QNX ne
vstroeny vnutr' Mikroyadra. Processy obsluzhivayushchie vvod/vyvod zapuskayutsya
dinamicheski vo vremya raboty sistemy. Tak kak fajlovaya sistema QNX yavlyaetsya
neobyazatel'nym elementom, to prostranstvo putej (polnyh imen fajlov i
katalogov) ne vstroeno vnutr' fajlovoj sistemy, v otlichie ot bol'shinstva
monolitnyh sistem.


Prefiksy i oblasti polnomochij
V QNX prostranstvo imen putej razdeleno na oblasti polnomochij.
Lyuboj process, vypolnyayushchij fajl-orientirovannoe obsluzhivanie
vvoda/vyvoda, dolzhen zaregistrirovat' u Menedzhera processov svoj prefiks,
opredelyaya chast' prostranstva imen, kotoroe on hochet kontrolirovat'
(t.e. oblast' svoih polnomochij).  |ti prefiksy sostavlyayut derevo
prefiksov, kotoroe hranitsya v pamyati na kazhdom komp'yutere pod
upravleniem QNX.



Razborka imen putej

Prefiksy menedzhera vvoda/vyvoda
Kogda process otkryvaet fajl, to polnoe imya fajla sopostavlyaetsya
s derevom prefiksov s tem, chtoby otpravit' zapros open() k
sootvetstvuyushchemu menedzheru resursov vvoda/vyvoda. Naprimer, Menedzher
ustrojstv (Dev) obychno registriruet prefiks /dev.
Esli process vyzyvaet open() s argumentom /dev/xxx,
to sovpadet prefiks /dev i open() budet napravlen k
Dev (ego vladel'cu).

Derevo prefiksov mozhet soderzhat' chastichno perekryvayushchiesya oblasti
polnomochij. V etom sluchae ishchetsya naibolee dlinnoe sovpadenie.
Naprimer, predpolozhim, chto est' tri zaregistrirovannyh prefiksa:


/
diskovaya fajlovaya sistema (Fsys)
/dev
sistema simvol'nyh ustrojstv (Dev)
/dev/hd0
diskovyj tom bez razdelov (Fsys)

Menedzher fajlovoj sistemy zaregistriroval dva prefiksa, odin dlya
smontirovannoj fajlovoj sistemy QNX (t.e. /) i odin dlya
blok-orientirovannogo fajla, kotoryj predstavlyaet ves' fizicheskij
zhestkij disk (t.e. /dev/hd0). Menedzher ustrojstv zaregistriroval
edinstvennyj prefiks. Sleduyushchaya tablica illyustriruet pravilo naibolee
dlinnogo sovpadeniya pri razbore imen putej.


Imya puti:
Sovpadaet:
Otnositsya k:
/dev/con1
/dev
Dev
/dev/hd0

/dev/hd0
Fsys
/usr/dtdodge/test
/
Fsys
Derevo prefiksov hranitsya kak spisok prefiksov, razdelennyh
dvoetochiyami, sleduyushchim obrazom:


prefix=pid,unit:prefix=pid,unit:prefix=pid,unit


gde pid - eto ID processa menedzhera resursov I/O, a unit -
eto odin simvol, ispol'zuemyj menedzherom dlya numeracii prefiksov, kotorymi
on vladeet.  V privedennom vyshe primere, esli Fsys byl by
processom 3 i Dev byl by processom 5, to derevo prefiksov
vyglyadelo by kak:


/dev/hd0=3,a:/dev=5,a:/=3,e



Esli vy hotite:
Ispol'zujte:

Pokazat' derevo prefiksov
Utilitu prefix
Poluchit' derevo prefiksov vnutri programmy na yazyke Si
Funkciyu qnx_prefix_query()

Setevoj koren'
QNX podderzhivayut koncepciyu setevogo kornya, kotoraya pozvolyaet
sopostavlyat' imya puti s derevom prefiksov na konkretnom uzle. Dlya
oboznacheniya uzla imya puti nachinaetsya s dvuh kosyh chert, za
kotorymi sleduet nomer uzla. |to takzhe pozvolyaet vam legko poluchat'
dostup k fajlu i ustrojstvu, kotorye lezhat za predelami prostranstva
putej vashego uzla. Naprimer, v tipichnoj seti QNX vozmozhny sleduyushchie
imena putej:


/dev/ser1
lokal'nyj posledovatel'nyj port
//10/dev/ser1
posledovatel'nyj port v uzle 10
//0/dev/ser1
lokal'nyj posledovatel'nyj port
//20/usr/dtdodge/test
fajl na uzle 20

 Zamet'te, chto //0 vsegda ukazyvaet na lokal'nyj uzel


Setevoj koren' po umolchaniyu
Kogda programma vypolnyaetsya na udalennom uzle, vy obychno hotite,
chtoby ona rassmatrivala imena putej v kontekste prostranstva imen
svoego uzla. Naprimer, eta komanda:


//5 ls /


kotoraya zapuskaet utilitu ls na uzle 5, vozvratit to zhe
samoe, chto i:


ls /


zapuskaemaya na svoem uzle. V oboih sluchayah "/" budet
sootnosit'sya s derevom prefiksov na vashem uzle, a ne na uzle 5.
V protivnom sluchae, mozhno predstavit' sebe besporyadok, kotoryj mog by
vozniknut', esli by prefiks "/" rassmatrivalsya svoim kak dlya
uzla 5, tak i dlya svoego uzla: vybiralis' by odnovremenno
fajly iz raznyh fajlovyh sistem!

CHtoby pravil'no interpretirovat' imena putej, kazhdyj process imeet
setevoj koren' po umolchaniyu, kotoryj opredelyaet, derevo prefiksov
kakogo uzla budet ispol'zovat'sya dlya razbora lyubyh imen putej,
nachinayushchihsya s odinochnoj kosoj cherty ("/").
Kogda razbiraetsya imya puti, nachinayushcheesya s odinochnoj kosoj cherty,
to ono predvaryaetsya setevym kornem po umolchaniyu. Naprimer, esli
process imeet setevoj koren' po umolchaniyu //9, togda:

/usr/home/luc
budet razbirat'sya, kak:
//9/usr/home/luc
chto mozhet byt' interpretirovano, kak "razobrat' put'
/usr/home/luc, ispol'zuya derevo prefiksov 9-go uzla".

Setevoj koren' po umolchaniyu nasleduetsya processami pri ih
sozdanii i sootvetstvuet lokal'nomu uzlu, na kotorom zapuskaetsya sistema.
Naprimer, dopustim, chto vy rabotaete na uzle 9, nahodyas' v komandnom
interpretatore, dlya kotorogo setevoj koren' po umolchaniyu ustanovlen kak
uzel 9 (ves'ma tipichnyj sluchaj). Esli vy vypolnite komandu:


ls /


komanda unasleduet setevoj koren' po umolchaniyu //9, i
v rezul'tate vy poluchite:


ls //9/


Podobno tomu, esli by vy vveli komandu:

//5 ls /


Vy zapustili komandu ls na uzle 5, no ona po-prezhnemu unasleduet
setevoj koren' po umolchaniyu //9, poetomu v rezul'tate vy opyat'
poluchite ls //9/. V oboih sluchayah imya puti razbiraetsya otnositel'no
odnogo i togo zhe prostranstva imen.


Esli vy hotite:
Ispol'zujte:
Poluchit' tekushchij setevoj koren' po umolchaniyu
Funkciyu qnx_prefix_getroot()
Ustanovit' setevoj koren' po umolchaniyu
Funkciyu qnx_prefix_setroot()
Zapustit' programmu s novym setevym kornem po umolchaniyu
Utilitu on

Peredacha imen putej mezhdu processami
Esli zapushcheno odnovremenno neskol'ko processov, oni ne
obyazatel'no imeyut odin i tot zhe setevoj koren' po umolchaniyu, dazhe esli
oni vypolnyayutsya na odnom i tom zhe uzle. K primeru, odin iz processov
mog unasledovat' setevoj koren' po umolchaniyu ot roditel'skogo processa
na kakom-libo drugom uzle seti, libo ego setevoj koren' po umolchaniyu
mog byt' v yavnom vide zadan roditel'skim processom.

Pri peredache imeni puti mezhdu processami, ch'i setevye korni mogut
otlichat'sya (naprimer, peredavaya fajl spuleru dlya pechati), vy dolzhny
dobavit' setevoj koren' v nachalo imeni puti, prezhde chem peredat' put'
drugomu processu. Esli vy uvereny, chto posylayushchij process i poluchatel'
imeyut odin i tot zhe setevoj koren' po umolchaniyu (ili imya puti uzhe
nachinaetsya s //uzel/), to vy mozhete opustit' etot shag.


Psevdonimy prefiksov
My rassmotreli prefiksy, kotorye registriruyutsya menedzherami
resursov I/O. Vtoraya forma prefiksa izvestna kak psevdonim
prefiksa, eto prostaya podstanovka stroki vmesto iskomogo prefiksa.
Psevdonim prefiksa imeet formu:


prefix=stroka-zamenitel'


Naprimer, vy rabotaete na mashine, u kotoroj net lokal'noj fajlovoj
sistemy (poetomu net i processa, kotoryj by otvechal za "/").
Odnako, fajlovaya sistema imeetsya na drugom uzle (dopustim, 10), i vy
hotite ee ispol'zovat' kak "/". Vy mozhete sdelat' eto s
pomoshch'yu sleduyushchego psevdonima prefiksa:


/=//10/


|to privedet k tomu, chto vedushchaya kosaya cherta (/) budet zamenyat'sya
na prefiks //10/.  Naprimer, put' /usr/dtdodge/test budet
zamenen sleduyushchim:

//10/usr/dtdodge/test
|to novoe imya puti budet snova sravnivat'sya s derevom prefiksov;
na etot raz budet ispol'zovat'sya uzhe derevo prefiksov 10 uzla, t.k.
imya puti nachinaetsya s //10. |to privedet k Menedzheru fajlovoj
sistemy na uzle 10, kotoromu i budet napravlen zapros, naprimer,
open(). S pomoshch'yu vsego lish' neskol'kih simvolov etot psevdonim
pozvolil nam obrashchat'sya k udalennoj fajlovoj sisteme kak k lokal'noj.

Dlya togo chtoby vypolnit' perenapravlenie, ne obyazatel'no
zapuskat' lokal'nuyu fajlovuyu sistemu. Derevo prefiksov dlya bezdiskovoj
rabochej stancii mozhet vyglyadet' primerno tak:


/dev=5,a:/=//10/


Pri takom dereve prefiksov nomera putej, nachinayushchihsya s /dev,
budut napravlyat'sya k lokal'nomu menedzheru simvol'nyh ustrojstv, v to
vremya kak zaprosy s lyubymi drugimi imenami putej, budut napravlyat'sya k
udalennoj fajlovoj sisteme.


Sozdanie special'nyh imen ustrojstv
Vy takzhe mozhete ispol'zovat' psevdonimy sozdaniya special'nyh imen
ustrojstv. Naprimer, esli spuler pechati zapushchen na uzle 20, to vy
mozhete sozdat' dlya nego lokal'nyj psevdonim sleduyushchim obrazom:


/dev/printer=//20/dev/spool


Lyuboj zapros na otkrytie lokal'nogo printera /dev/printer
budet napravlyat'sya po seti k real'nomu spuleru. Analogichnym obrazom,
esli ne sushchestvuet lokal'nogo diskovoda dlya gibkih diskov, psevdonim
dlya udalennogo diskovoda na uzle 20 mozhet imet' vid:


/dev/fd0=//20/dev/fd0


V oboih rassmotrennyh vyshe sluchayah mozhno ne ispol'zovat'
perenapravlenie s pomoshch'yu psevdonima, a obrashchat'sya neposredstvenno k
udalennomu resursu sleduyushchim obrazom:

//20/dev/spool  ILI  //20/dev/fd0


Otnositel'nye puti
Put' ne obyazatel'no dolzhen nachinat'sya s odnoj ili dvuh kosyh
chert. V takih sluchayah put' schitaetsya otnositel'nym po otnosheniyu k
tekushchemu rabochemu katalogu. QNX hranit tekushchij rabochij katalog v
vide stroki simvolov. Otnositel'nye puti preobrazuyutsya v polnye
setevye imena puti dobavleniem tekushchego rabochego kataloga v nachalo
otnositel'nogo puti.

Uchtite, chto rezul'tat zavisit ot togo, nachinaetsya li tekushchij
rabochij katalog s odinarnoj kosoj cherty, libo s setevogo kornya.


Tekushchij rabochij katalog
Esli tekushchij rabochij katalog nachinaetsya s dvojnoj kosoj cherty
(setevogo kornya), on nazyvaetsya opredelennym i privyazan k
prostranstvu imen ukazannogo uzla. V protivnom sluchae, esli on
nachinaetsya s odinarnoj kosoj cherty, to v nachalo dobavlyaetsya setevoj
koren' po umolchaniyu.

Naprimer, eta komanda:


cd //18/


yavlyaetsya primerom pervoj (opredelennoj) formy i privyazyvaet
posleduyushchie razbory otnositel'nyh putej k uzlu 18, nezavisimo ot togo,
kakoe znachenie setevogo kornya po umolchaniyu. Vypolniv zatem komandu
cd dev, vy popadete v //18/dev.

S drugoj storony, takaya komanda:

cd /


yavlyaetsya primerom vtoroj formy, kogda setevoj koren' po umolchaniyu
vliyaet na razbor otnositel'nogo puti. Naprimer, esli setevoj koren' po
umolchaniyu //9, togda, vypolniv komandu cd dev, vy popadete
v //9/dev. Tak kak tekushchij rabochij katalog ne nachinaetsya s
ukazaniya uzla, to setevoj koren' po umolchaniyu dobavlyaetsya dlya polucheniya
polnogo setevogo puti.

|to na samom dele ne tak slozhno, kak mozhet pokazat'sya. Obychno
setevye korni (//uzel/) ne ukazyvayutsya, i vse,
chto vy delaete, prosto rabotaet vnutri prostranstva imen vashego uzla
(opredelyaemogo vashim setevym kornem po umolchaniyu). Bol'shinstvo
pol'zovatelej, vojdya v sistemu, prinimayut normal'nyj setevoj koren'
po umolchaniyu (t.e. prostranstvo imen ih sobstvennogo uzla) i rabotayut
vnutri etoj sredy.


Zamechanie o cd
V nekotoryh tradicionnyh UNIX sistemah komanda cd (smenit'
direktoriyu) modificiruet zadannyj put', esli on soderzhit simvol'nye
ssylki. Kak rezul'tat, put' k novomu tekushchemu rabochemu katalogu -
kotoryj mozhno posmotret' komandoj pwd, mozhet otlichat'sya ot
togo, kotoryj byl zadan v komande cd.

V QNX, odnako, cd ne izmenyaet put' - za isklyucheniem
sokrashchennyh ssylok "..".  Naprimer:


cd /usr/home/luc/test/../doc


ustanovit tekushchij rabochij katalog /usr/home/luc/doc, dazhe
esli nekotorye elementy etogo puti yavlyayutsya simvolicheskimi svyazyami.

Bolee podrobnuyu informaciyu o simvolicheskih svyazyah mozhno poluchit'
v glave "Menedzher fajlovoj sistemy".




 CHtoby poluchit' polnoe setevoe imya puti, ispol'zujte utilitu
fullpath.






Prostranstvo deskriptorov fajlov
Pri otkrytii resursa I/O, open() vozvrashchaet celoe chislo,
nazyvaemoe deskriptor fajla (FD), kotoroe ispol'zuetsya zatem,
chtoby napravlyat' vse posleduyushchie zaprosy I/O k dannomu menedzheru. (Vnutri
bibliotechnyh procedur dlya napravleniya oprosa ispol'zuetsya vyzov yadra
Sendfd().)

Prostranstvo deskriptorov fajlov, v otlichie ot prostranstva imen
puti, polnost'yu lokal'no dlya kazhdogo processa. Menedzher ispol'zuet
sochetanie PID i FD, chtoby opredelit' upravlyayushchuyu strukturu, sozdannuyu
predydushchim vyzovom open(). |ta struktura nazyvaetsya blok
upravleniya fajlom (OCB ot anglijskogo open control block) i
hranitsya vnutri menedzhera I/O.

Sleduyushchaya diagramma pokazyvaet, kak menedzher I/O nahodit
sootvetstvuyushchij OCB dlya pary PID i FD.





PID i FD opredelyayut OCB dlya Menedzhera vvoda/vyvoda.



Bloki upravleniya fajlami
OCB soderzhit dejstvuyushchuyu informaciyu ob otkrytom resurse.
Naprimer, fajlovaya sistema hranit zdes' tekushchij ukazatel' na poziciyu v
fajle. Kazhdyj vyzov open() sozdaet novyj OCB. Takim obrazom, esli
process dvazhdy otkryvaet odin i tot zhe fajl, lyubye vyzovy lseek(),
ispol'zuyushchie odin FD, ne povliyayut na tekushchuyu poziciyu dlya drugogo FD.

To zhe samoe spravedlivo i dlya razlichnyh processov, otkryvayushchih
odin i tot zhe fajl.

Sleduyushchaya diagramma pokazyvaet dva processa, odin iz kotoryh
otkryvaet fajl dvazhdy, a drugoj otkryvaet etot zhe fajl odin raz.  Pri
etom net razdelyaemyh FD.





Process A otkryvaet fajl /tmp/file dvazhdy. Process B otkryvaet
tot zhe fajl odin raz.




Neskol'ko deskriptorov fajla v odnom ili neskol'kih processah
mogut ukazyvat' na odin i tot zhe OCB. |to mozhet byt' dostignuto dvumya
sposobami:

 process mozhet ispol'zovat' funkcii Si dup(),
dup2() ili fcntl() dlya sozdaniya dublikata deskriptora
fajla, kotoryj ukazyvaet na tot zhe samyj OCB;

 pri sozdanii novogo processa posredstvom fork(),
spawn() ili exec(), vse deskriptory otkrytyh fajlov
po umolchaniyu nasleduyutsya novym processom; eti nasleduemye deskriptory
ukazyvayut na te zhe samye OCB, chto i sootvetstvuyushchie deskriptory fajla
v roditel'skom processe.


Kogda neskol'ko FD ukazyvayut na odin i tot zhe OCB, togda lyuboe
izmenenie v sostoyanii OCB nemedlenno vidimo dlya vseh processov, u
kotoryh est' deskriptory fajlov, ukazyvayushchie na etot OCB.

Naprimer, esli odin iz processov ispol'zuet funkciyu lseek()
dlya izmeneniya tekushchej pozicii, togda chtenie ili zapis' nachinaetsya s novoj
pozicii, nezavisimo ot togo, kakoj iz deskriptorov fajla ispol'zuetsya.

Sleduyushchaya diagramma pokazyvaet dva processa, iz kotoryh odin
otkryvaet fajl dvazhdy, a zatem vyzyvaet dup(), chtoby poluchit'
tretij deskriptor. Zatem on sozdaet dochernij process, kotoryj nasleduet
vse otkrytye fajly.





Process otkryvaet fajl dvazhdy, a zatem poluchaet tretij FD
posredstvom dup().  Ego dochernij process unasleduet vse eti tri
deskriptora fajla.




Vy mozhete predotvratit' nasledovanie deskriptora fajla pri
ispol'zovanii spawn() ili exec(), predvaritel'no
vyzvav funkciyu fcntl() i ustanoviv flag FD_CLOEXEC.









Menedzher fajlovoj sistemy

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
chto takoe fajl?
regulyarnye fajly i katalogi;
svyazi i indeksnye deskriptory (inodes);
simvolicheskie svyazi;
programmnye kanaly (pipes) i FIFO;
proizvoditel'nost' Menedzhera fajlovoj sistemy;
nadezhnost' fajlovoj sistemy;
rabota s diskami;
klyuchevye komponenty razdela QNX;
menedzher fajlovoj sistemy DOS;
fajlovaya sistema CD-ROM;
fajlovaya sistema flesh;
fajlovaya sistema NFS;
fajlovaya sistema SMB.



Vvedenie
Menedzher fajlovoj sistemy (Fsys) obespechivaet standartizovannye
sposoby sohraneniya dannyh na diskah i dostupa k nim. Fsys otvechaet
za obrabotku vseh zaprosov na otkrytie, zakrytie, chtenie i zapis' fajlov.



CHto takoe fajl?
V QNX fajl - eto ob®ekt, v kotoryj mozhet proizvodit'sya
zapis', iz kotorogo mozhet proizvodit'sya chtenie, libo i to i drugoe.
QNX podderzhivaet shest' tipov fajlov; pyat' iz nih podderzhivaet
Fsys:

 regulyarnye fajly - sostoyat iz posledovatel'nosti bajt s
proizvol'nym dostupom i ne imeyut predopredelennoj struktury;

 katalogi - soderzhat informaciyu, neobhodimuyu dlya poiska
regulyarnyh fajlov; takzhe soderzhat status i atributy dlya kazhdogo
regulyarnogo fajla;

 simvolicheskie svyazi - soderzhat put' k fajlu ili
katalogu, k kotorym perenapravlyayutsya vse zaprosy; simvolicheskie svyazi
chasto ispol'zuyutsya dlya predostavleniya mnozhestva putej k odnomu fajlu;

 programmnye kanaly (pipes) i FIFO - sluzhat kak kanaly
vvoda/vyvoda mezhdu vzaimodejstvuyushchimi processami;

 blok-orientirovannye fajly - otnosyatsya k ustrojstvam,
takim, kak diski, lenty i razdely diskov. Dostup k etim fajlam obychno
osushchestvlyaetsya takim obrazom, chto apparatnye harakteristiki ustrojstv
skryty ot prilozhenij.


Vse eti tipy fajlov podrobno opisyvayutsya v etoj glave. SHestoj tip
fajlov - blok-orientirovannye fajly - obsluzhivaetsya Menedzherom
ustrojstv.


Metki daty i vremeni
Fsys podderzhivaet chetyre razlichnyh metki vremeni dlya kazhdogo
fajla. |to:

 data poslednego dostupa (chteniya);
 data poslednej zapisi;
 data poslednej modifikacii;
 data sozdaniya (unikal'na dlya QNX).

Dostup k fajlam
Dostup k regulyarnym fajlam i katalogam upravlyaetsya bitami
rezhima, hranyashchimisya v inode (indeksnom deskriptore) fajla.
Bolee podrobno inode opisan v sekcii "Svyazi
i indeksnye deskriptory (inodes)". |ti bity razreshayut chtenie, zapis' i
vypolnenie v zavisimosti ot effektivnyh ID pol'zovatelya i gruppy.
Pri etom pol'zovateli delyatsya na tri kategorii:

 vladelec fajla;
 chleny gruppy, k kotoroj prinadlezhit vladelec;
 ostal'nye.
Process mozhet vypolnyat'sya s ID pol'zovatelya ili ID
gruppy fajla, a ne roditel'skogo processa. Mehanizm, kotoryj pozvolyaet eto,
nazyvaetsya setuid (ustanovit' ID pol'zovatelya) i setgid
(ustanovit' ID gruppy).



Regulyarnye fajly i katalogi

Regulyarnye fajly
QNX rassmatrivaet regulyarnyj fajl kak posledovatel'nost' bajt s
vozmozhnost'yu proizvol'nogo dostupa i ne imeyushchuyu drugoj
predopredelennoj vnutrennej struktury. Prikladnye programmy sami nesut
otvetstvennost' za ponimanie struktury i soderzhaniya konkretnogo
regulyarnogo fajla.

Regulyarnye fajly sostavlyayut bol'shinstvo fajlov v fajlovyh
sistemah. Fajlovye sistemy podderzhivayutsya Menedzherom fajlovoj sistemy
i realizovany na baze blok-orientirovannyh fajlov, sootvetstvuyushchih
razdelam diska (razdely opisany v sekcii "Rabota s
diskami").


Katalogi
Katalog - eto fajl, kotoryj soderzhit elementy kataloga.
Kazhdyj element kataloga uvyazyvaet imya fajla s fajlom.
Imya fajla - eto simvol'noe imya, kotoroe pozvolyaet identificirovat'
fajl i rabotat' s nim. Fajl mozhet byt' identificirovan neskol'kimi
imenami (smotri sekcii "Svyazi i indeksnye
deskriptory (inodes)" i "Simvolicheskie svyazi").

Sleduyushchaya diagramma pokazyvaet, kak proizvoditsya poisk fajla s
imenem /usr/bill/file2.





Put' v strukture kataloga QNX k fajlu /usr/bill/file2.



Operacii s katalogami
Hotya katalog vedet sebya vo mnogom kak standartnyj fajl,
Menedzher fajlovoj sistemy nakladyvaet nekotorye ogranicheniya na
operacii, kotorye vy mozhete proizvodit' s katalogom. V chastnosti, vy
ne mozhete otkryt' katalog dlya zapisi libo sozdat' svyaz' dlya
kataloga s pomoshch'yu funkcii Si link().


CHtenie elementov kataloga
Dlya chteniya elementov kataloga vy mozhete ispol'zovat' nabor funkcij Si,
opredelennyh POSIX, kotorye obespechivayut ne zavisimyj ot OS dostup k
elementam kataloga. |ti funkcii vklyuchayut:

opendir()
readdir()
rewinddir()
closedir()
Tak kak katalogi QNX - eto prosto fajly, soderzhashchie "izvestnuyu"
informaciyu, vy mozhete takzhe chitat' elementy kataloga neposredstvenno
funkciyami Si open() i read(). Odnako eta tehnika ne
perenosima - format elementov kataloga otlichaetsya v razlichnyh operacionnyh
sistemah.


|kstenty
V QNX regulyarnye fajly i fajly kataloga hranyatsya kak
posledovatel'nost' ekstentov. |kstent - eto nepreryvnaya
posledovatel'nost' blokov na diske.


Gde hranyatsya ekstenty
Fajly, kotorye sostoyat tol'ko iz odnogo ekstenta, hranyat
informaciyu ob ekstente v elemente kataloga. No, esli fajl sostoit
bolee chem iz odnogo ekstenta, informaciya o raspolozhenii ekstentov
hranitsya v odnom ili bolee svyaznyh blokah ekstentov
(svyaznye - imeyushchie pryamye/obratnye ukazateli).
Kazhdyj blok ekstentov mozhet soderzhat' informaciyu ne bolee chem o 60
ekstentah.





Fajl, sostoyashchij iz mnozhestva nepreryvnyh oblastej na diske,
nazyvaemyh v QNX ekstentami.



Uvelichenie fajlov
Kogda Menedzheru fajlovoj sistemy neobhodimo uvelichit' fajl, on
snachala pytaetsya uvelichit' poslednij ekstent, hotya by dazhe na odin blok.
No esli poslednij ekstent ne mozhet byt' dopolnen, to dlya rasshireniya fajla
vydelyaetsya novyj ekstent.

Dlya vydeleniya novyh ekstentov Menedzher fajlovoj sistemy ispol'zuet
metod "pervogo popadaniya". Special'naya tablica v Menedzhere fajlovoj sistemy
soderzhit svedeniya obo vseh blokah, opisannyh v fajle /.bitmap (etot
fajl opisan v sekcii "Klyuchevye komponenty razdela
QNX"). Dlya kazhdogo bloka ukazyvaetsya razmer sootvetstvuyushchego emu
svobodnogo ekstenta. Menedzher fajlovoj sistemy vybiraet iz tablicy pervyj
dostatochno bol'shoj ekstent.



Svyazi i indeksnye deskriptory (inodes)
V QNX fajl mozhet oboznachat'sya bolee chem odnim imenem. Kazhdoe imya
fajla nazyvaetsya svyaz'yu. V dejstvitel'nosti sushchestvuet dva vida
svyazej: zhestkie svyazi, ili prosto "svyazi", i simvolicheskie svyazi.
Simvolicheskie svyazi opisany v sleduyushchej sekcii.

Dlya podderzhki svyazej kazhdogo fajla, imya fajla otdelyaetsya ot ostal'noj
informacii, opisyvayushchej fajl. |ta informaciya hranitsya v strukture,
nazyvaemoj inode (indeksnym deskriptorom).

Esli fajl imeet tol'ko odnu svyaz' (t.e. odno imya), to
blok inode hranitsya v elemente kataloga dlya etogo fajla.
No esli fajl imeet bolee chem odnu svyaz', to inode hranitsya
kak zapis' v special'nom fajle /.inodes, a element
kataloga dlya fajla soderzhit ukazatel' na zapis' inode.

Uchtite, chto vy mozhete sozdat' svyaz' dlya fajla, tol'ko esli fajl i
svyaz' nahodyatsya v odnoj i toj zhe fajlovoj sisteme.





Odin i tot zhe fajl oboznachen dvumya svyazyami s imenami "more" i
"less".


Sushchestvuet eshche dve situacii, v kotoryh dlya fajla sozdaetsya zapis'
v fajle /.inodes:

esli imya fajla dlinnee chem 16 simvolov, to informaciya
inode hranitsya v fajle /.inodes, ostavlyaya mesto v elemente
kataloga dlya 48-simvol'nogo imeni fajla;

esli fajl imel bolee odnoj svyazi i vse svyazi, krome odnoj, byli
udaleny, to za fajlom sohranyaetsya otdel'naya zapis' v fajle /.inodes.
|to sdelano, chtoby izbezhat' poiska elementa kataloga, ukazyvayushchego
na inode (elementy inode ne imeyut obratnyh svyazej s elementami
kataloga).


Esli vy hotite:
Ispol'zujte:

Sozdat' svyaz' iz komandnogo interpretatora
Utilitu ln
Sozdat' svyaz' iz programmy
Funkciyu link()

Udalenie svyazej
Pri sozdanii fajla, dlya nego ustanavlivaetsya schetchik svyazej,
ravnyj edinice. Po mere dobavleniya ssylok etot schetchik uvelichivaetsya;
pri udalenii svyazi schetchik svyazej umen'shaetsya.  Fajl ne udalyaetsya s
diska do togo, kak schetchik svyazej stanet ravnym nulyu i vse
programmy, ispol'zuyushchie etot fajl, zakroyut ego. |to pozvolyaet ispol'zovat'
otkrytyj fajl dazhe posle togo, kak u nego udaleny vse svyazi.


Esli vy hotite:
Ispol'zujte:
Udalit' svyaz' iz komandnogo interpretatora
Utilitu rm
Udalit' svyaz' iz programmy
Funkcii remove() ili unlink()

Svyazi kataloga
Vy ne mozhete sozdavat' zhestkie svyazi dlya kataloga. Odnako
kazhdyj katalog imeet dve zhestko opredelennye svyazi:

.  ("tochka")
..  ("tochka tochka")
Imya fajla "tochka" sootvetstvuet tekushchemu katalogu; "tochka tochka"
sootvetstvuet katalogu, predshestvuyushchemu tekushchemu katalogu.

Zamet'te, chto "tochka tochka" dlya kataloga "/" - eto prosto "/", -
vy ne mozhete podnyat'sya vyshe.



Simvolicheskie svyazi
Simvolicheskaya svyaz' - eto osobyj fajl, kotoryj soderzhit v kachestve
dannyh imya puti. Kogda simvolicheskaya svyaz' ispol'zuetsya v zaprose
vvoda/vyvoda - naprimer, open(), - oboznachenie svyazi v imeni puti
zamenyaetsya ee "dannymi". Simvolicheskaya svyaz' yavlyaetsya gibkim sredstvom
dlya perenapravleniya puti i chasto ispol'zuetsya dlya sozdaniya mnozhestva
putej k odnomu i tomu zhe fajlu. V otlichie ot zhestkih svyazej,
simvolicheskie svyazi mogut vyhodit' za predely fajlovoj sistemy i takzhe
yavlyat'sya svyazyami dlya katalogov.

V sleduyushchem primere katalogi //1/usr/fred i
//2/usr/barney yavlyayutsya svyazyami na odin i tot zhe katalog,
hotya oni nahodyatsya v razlichnyh fajlovyh sistemah, i dazhe na razlichnyh
uzlah (smotri sleduyushchuyu diagrammu). |to ne mozhet byt' sdelano s
ispol'zovaniem zhestkih svyazej:

//1/usr/fred --> //2/usr/barney
Zamet'te, chto simvolicheskaya svyaz' i adresuemyj katalog ne
obyazany imet' odno i to zhe imya. V bol'shinstve sluchaev simvolicheskie
svyazi ispol'zuyutsya dlya privyazki odnogo kataloga k drugomu. Odnako
oni takzhe mogut byt' ispol'zovany dlya fajlov, kak v etom primere:

//1/usr/eric/src/test.c --> //1/usr/src/game.c



Esli vy hotite:
Ispol'zujte utilitu:

Sozdat' simvolicheskuyu svyaz'
ln (s opciej -s)
Udalit' simvolicheskuyu svyaz'*
rm
Uznat', yavlyaetsya li fajl simvolicheskoj svyaz'yu
ls
* Pomnite, chto udalenie simvolicheskoj svyazi dejstvuet tol'ko
na svyaz', a ne na adresuemyj ob®ekt

Nekotorye funkcii operiruyut neposredstvenno s simvolicheskimi
svyazyami. Dlya etih funkcij zamena oboznacheniya svyazi v puti na ee
soderzhimoe ne proizvoditsya. K etim funkciyam otnosyatsya unlink()
(kotoraya udalyaet simvolicheskuyu svyaz'), lstat() i readlink().

Tak kak simvolicheskie svyazi mogut ukazyvat' na katalogi, to nevernaya
konfiguraciya mozhet privesti k problemam, takim, kak ciklicheskie
svyazi. CHtoby zashchitit'sya ot ciklicheskih svyazej, sistema nakladyvaet
ogranicheniya na kolichestvo perehodov; etot predel opredelen kak
SYMLOOP_MAX vo vklyuchaemom fajle <limits.h>.



Programmnye kanaly (pipes) i FIFO

Programmnye kanaly (pipes)
Programmnyj kanal - eto neimenovannyj fajl, kotoryj sluzhit
kak kanal vvoda/vyvoda mezhdu dvumya ili bolee vzaimodejstvuyushchimi processami -
odin process pishet v programmnyj kanal, drugoj chitaet iz programmnogo
kanala. Menedzher fajlovoj sistemy obespechivaet buferizaciyu dannyh. Razmer
bufera opredelen kak PIPE_BUF v fajle <limits.h>.
Programmnyj kanal udalyaetsya posle togo kak zakryty oba ego konca.

Programmnye kanaly obychno ispol'zuyutsya, kogda dva processa hotyat
vypolnyat'sya parallel'no, s odnonapravlennoj peredachej dannyh ot odnogo
processa k drugomu. Esli trebuetsya dvunapravlennaya peredacha dannyh,
to dolzhny ispol'zovat'sya soobshcheniya.

Tipichnoe primenenie programmnogo kanala
sostoit v soedinenii vyvoda odnoj programmy s vvodom drugoj programmy.
|to soedinenie chasto proizvoditsya komandnym interpretatorom (Shell).
Naprimer:

ls | more
napravlyaet standartnyj vyvod ot utility ls cherez
programmnyj kanal v standartnyj vvod utility more.


Esli vy hotite:
Ispol'zujte:

Sozdat' programmnyj kanal iz komandnogo interpretatora
Simvol programmnogo kanala ("|")
Sozdat' programmnyj kanal iz programmy
Funkcii pipe() ili popen()




Na bezdiskovyh rabochih stanciyah vy mozhete zapustit' Menedzher
programmnyh kanalov (Pipe) vmesto Menedzhera fajlovoj sistemy,
kogda trebuyutsya tol'ko programmnye kanaly. Menedzher programmnyh kanalov
optimizirovan dlya kanal'nogo (konvejernogo) vvoda/vyvoda i mozhet
obespechit' bol'shuyu propusknuyu sposobnost', chem Menedzher fajlovoj sistemy.

 




FIFO
FIFO - eto po sushchestvu to zhe samoe, chto i programmnye kanaly, za
isklyucheniem togo, chto FIFO yavlyayutsya imenovannymi postoyannymi fajlami,
kotorye hranyatsya v katalogah fajlovoj sistemy.


Esli vy hotite:
Ispol'zujte:
Sozdat' FIFO iz komandnogo interpretatora
Utilitu mkfifo
Sozdat' FIFO iz programmy
Funkciyu mkfifo()
Udalit' FIFO iz komandnogo interpretatora
Utilitu rm
Udalit' FIFO iz programmy
Funkcii remove() ili unlink()


Proizvoditel'nost' Menedzhera fajlovoj sistemy
Svojstva Menedzhera fajlovoj sistemy, obespechivayushchie
vysokoproizvoditel'nyj dostup k disku:

 liftovyj poisk;
 kesh-bufer;
 mnogopotokovaya obrabotka;
 klient-upravlyaemyj prioritet;
 vremennye fajly;
 psevdodiski.

Liftovyj poisk
Liftovyj poisk minimiziruet obshchie
zatraty vremeni na pozicionirovanie magnitnoj golovki pri chtenii ili
zapisi na disk. Zaprosy vvoda/vyvoda uporyadochivayutsya takim obrazom,
chtoby vse oni mogli byt' vypolneny za odin prohod magnitnoj golovki,
ot samogo mladshego k samomu starshemu adresu na diske.

Liftovyj poisk takzhe imeet usovershenstvovanie, obespechivayushchee
vypolnenie mul'tisektornogo vvoda/vyvoda tam, gde vozmozhno.


Kesh-bufer
Kesh-bufer - eto intellektual'nyj bufer mezhdu Menedzherom
fajlovoj sistemy i drajverom diska. Kesh-bufer hranit bloki fajlov s cel'yu
minimizirovat' kolichestvo obrashchenij Menedzhera fajlovoj sistemy k
disku. Po umolchaniyu razmer kesha opredelyaetsya obshchim ob®emom
operativnoj pamyati, no vy mozhete zadat' drugoe znachenie cherez opciyu
pri zapuske Fsys.

Operacii chteniya yavlyayutsya sinhronnymi. Operacii zapisi, naprotiv,
obychno yavlyayutsya asinhronnymi. Kogda dannye popadayut v kesh, Menedzher
fajlovoj sistemy otvechaet klientu (funkciej Reply()), izveshchaya
ego, chto dannye zapisany. Zatem vypolnyaetsya zapis' dannyh na disk s
maksimal'no-vozmozhnoj skorost'yu, obychno ne pozdnee, chem cherez pyat'
sekund.

Prilozheniya mogut izmenyat' mehanizm zapisi primenitel'no k
konkretnym fajlam. Naprimer, prilozhenie, rabotayushchee s bazoj dannyh,
mozhet potrebovat', chtoby zapis' v opredelennyj fajl proizvodilas'
sinhronno. |to obespechit vysokij uroven' celostnosti fajla v sluchae
apparatnogo ili programmnogo sboya.


Mnogopotokovaya obrabotka
Menedzher fajlovoj sistemy yavlyaetsya mnogopotokovym processom, i,
takim obrazom, on mozhet obrabatyvat' neskol'ko zaprosov vvoda/vyvoda
odnovremenno. |to pozvolyaet Menedzheru fajlovoj sistemy v polnoj mere
realizovat' vozmozhnosti parallel'noj obrabotki, tak kak on v
sostoyanii:

poluchit' odnovremennyj dostup k neskol'kim ustrojstvam;

udovletvorit' zaprosy vvoda/vyvoda iz kesh-bufera, v to vremya
kak vypolnyayutsya drugie zaprosy vvoda/vyvoda, osushchestvlyayushchie dostup k
disku.


Klient-upravlyaemyj prioritet
Prioritet Menedzhera fajlovoj sistemy mozhet opredelyat'sya
prioritetom processa, poslavshego emu zapros. V etom sluchae, kogda
Menedzher fajlovoj sistemy poluchaet soobshchenie, ego prioritet
ustanavlivaetsya ravnym prioritetu processa, poslavshego soobshchenie.
Bolee podrobno ob etom govoritsya v razdele
"Dispetcherizaciya processov"
glavy "Mikroyadro".


Vremennye fajly
QNX predusmatrivaet vozmozhnost' otkrytiya vremennyh fajlov, t.e.
fajlov, kotorye zapisyvayutsya i zatem chitayutsya v techenie korotkogo
promezhutka vremeni. Dlya takih fajlov Menedzher fajlovoj sistemy
staraetsya hranit' bloki dannyh v kesh-bufere i proizvodit zapis' blokov
na disk tol'ko v sluchae krajnej neobhodimosti.


Psevdodiski
Menedzher fajlovoj sistemy soderzhit vstroennuyu vozmozhnost'
podderzhki elektronnogo diska, pozvolyayushchuyu ispol'zovat' do 8 Megabajt
operativnoj pamyati v kachestve psevdodiska.  Tak kak Menedzher fajlovoj
sistemy ispol'zuet vysokoeffektivnyj mehanizm sostavnyh soobshchenij, to
dannye iz psevdodiska kopiruyutsya neposredstvenno v prilozhenie.

Menedzher fajlovoj sistemy v sostoyanii obojti keshirovanie, tak kak
psevdodisk yavlyaetsya vstroennym, a ne realizovan kak otdel'nyj drajver.
Dlya informacii ob obmene sostavnymi soobshcheniyami, smotri razdel
"Dopolnitel'nye vozmozhnosti"
v glave "Mikroyadro".

Tak kak psevdodiski isklyuchayut apparatnye zaderzhki i ne ispol'zuyut
keshirovanie dannyh, poetomu oni obespechivayut bol'shij determinizm pri
vypolnenii operacij vvoda/vyvoda po sravneniyu s zhestkimi diskami.



Nadezhnost' fajlovoj sistemy
V QNX vysokaya proizvoditel'nost' fajlovoj sistemy dostigaetsya ne
za schet snizheniya nadezhnosti. |to obespechivaetsya neskol'kimi sposobami.

V to vremya kak bol'shaya chast' dannyh pomeshchaetsya v kesh-bufer i
zapisyvaetsya s nebol'shoj zaderzhkoj, kriticheskie dlya fajlovoj sistemy
dannye zapisyvayutsya nemedlenno. Obnovleniya katalogov, indeksnyh deskriptorov
(inodes), blokov ekstentov i bitovoj karty proizvodyatsya bez zaderzhki, chtoby
garantirovat' celostnost' struktury fajlovoj sistemy na diske (t.e.
chto ne budet vnutrennego nesootvetstviya dannyh na diske).

Inogda vse perechislennye vyshe struktury dannyh dolzhny byt'
obnovleny. Naprimer, esli vy peremeshchaete fajl v kataloge, poslednij
ekstent kotorogo zapolnen, to katalog dolzhen vyrasti. V takih
sluchayah poryadok operacij tshchatel'no podobran takim obrazom, chto dazhe
esli proizojdet katastroficheskij sboj v moment, kogda operaciya eshche ne
polnost'yu zavershena (naprimer, otklyuchenie pitaniya), to fajlovaya
sistema posle perezapuska vse zhe sohranit rabotosposobnost'. V hudshem
sluchae, nekotorye bloki budut vydeleny, no ne ispol'zovany. Ispravit'
podobnuyu situaciyu mozhno, zapustiv utilitu chkfsys.


Vosstanovlenie fajlovoj sistemy
Dazhe samye nadezhnye sistemy ne zastrahovany ot avarijnyh
situacij, takih kak:

 poyavlenie plohih blokov na diske v rezul'tate broskov ili
provalov napryazheniya;

 neumelyj ili zlonamerennyj pol'zovatel', imeyushchij dostup k
privilegiyam administratora sistemy, vypolnil inicializaciyu fajlovoj
sistemy (utilitoj dinit);

 nekorrektnaya programma (v osobennosti, vypolnyayushchayasya ne v srede
QNX) ignoriruet informaciyu o razdelah diska i perezapisyvaet chast'
razdela QNX.


CHtoby posle takih situacij mozhno bylo vosstanovit' kak mozhno bol'she
fajlov, na disk zapisyvayutsya unikal'nye "signatury" dlya avtomaticheskoj
identifikacii i vosstanovleniya kriticheskih chastej fajlovoj sistemy.
Fajl s indeksnymi deskriptorami (/.inodes), tak zhe kak i kazhdyj
katalog, i blok ekstentov, vse soderzhat unikal'nye obrazcy dannyh,
kotorye mogut byt' ispol'zovany utilitoj chkfsys dlya
vosstanovleniya ser'ezno povrezhdennoj fajlovoj sistemy.

Bolee podrobnaya informaciya o vosstanovlenii fajlovoj sistemy
soderzhitsya v dokumentacii k utilite chkfsys.



Rabota s diskami
Menedzher fajlovoj sistemy upravlyaet blok-orientirovannymi fajlami.
|ti fajly opredelyayut diski i razdely diskov.


Diski i diskovye podsistemy
QNX schitaet kazhdyj fizicheskij disk na komp'yutere blok-orientirovannym
fajlom. Kak blok-orientirovannyj fajl, disk rassmatrivaetsya fajlovoj sistemoj
QNX kak posledovatel'nost' blokov razmerom po 512 bajt, nezavisimo ot
razmera diska. Bloki numeruyutsya, nachinaya s pervogo bloka na diske (blok 1).

Tak kak kazhdyj disk yavlyaetsya blok-orientirovannym fajlom, on mozhet
byt' otkryt kak odno celoe dlya nizkourovnevogo dostupa s ispol'zovaniem
standartnyh POSIX Si funkcij, takih kak open(), read(),
write() i close(). Na urovne blok-orientirovannogo fajla,
kotoryj opredelyaet celyj disk, QNX ne delaet absolyutno nikakih predpolozhenij
o kakih-libo strukturah dannyh, kotorye mogut sushchestvovat' na diske.

Komp'yuter pod upravleniem QNX mozhet imet' odnu ili neskol'ko
diskovyh podsistem. Kazhdaya diskovaya podsistema sostoit iz
kontrollera i odnogo ili bolee diskov. Vy zapuskaete drajver ustrojstva
dlya kazhdoj diskovoj podsistemy, kotoraya dolzhna upravlyat'sya Menedzherom
fajlovoj sistemy.


Razdely OS
QNX sootvetstvuet promyshlennomu standartu de-fakto, kotoryj
pozvolyaet razlichnym operacionnym sistemam razdelyat' odin i tot zhe
fizicheskij disk. V sootvetstvii s etim standartom, tablica razdelov
mozhet opredelyat' do chetyreh pervichnyh razdelov na diske. Tablica
hranitsya v pervom bloke diska.

Kazhdyj razdel dolzhen imet' "tip", uznavaemyj operacionnoj
sistemoj, kotoraya dolzhna ispol'zovat' etot razdel. Sleduyushchij spisok
soderzhit ispol'zuemye na dannyj moment tipy razdelov:


Tip:    
Operacionnaya sistema
1       
DOS (12-bitnaya FAT)
4       
DOS (16-bitnaya FAT; razdely <32Mbajt)
5       
Rasshirennyj razdel DOS
6       
DOS 4.0 (16-bitnaya FAT; razdel >=32Mbajt)
7       
OS/2 HPFS
7       
Predydushchaya versiya QNX 2 (do 1988)
8       
QNX 1.x i 2.x ("qny")
9       
QNX 1.x i 2.x ("qnz")
11      
DOS 32-bitnaya FAT; razdely do 2047Gbajt
12      
To zhe, chto tip 11, no ispol'zuet LBA rasshireniya preryvaniya Int 13h
14      
To zhe, chto tip 6, no ispol'zuet LBA rasshireniya preryvaniya Int 13h
15      
To zhe, chto tip 5, no ispol'zuet LBA rasshireniya preryvaniya Int 13h
77      
QNX POSIX razdel
78      
QNX POSIX razdel (vtorichnyj)
79      
QNX POSIX razdel (vtorichnyj)
99      
UNIX

Esli vy hotite imet' neskol'ko razdelov QNX 4.x na odnom
fizicheskom diske, vam sleduet ispol'zovat' tip 77 dlya pervogo QNX
razdela, tip 78 dlya vtorogo QNX razdela, i tip 79 dlya tret'ego.  Vy
mozhete ispol'zovat' drugie tipy dlya vtorogo i tret'ego QNX razdelov,
no 78 i 79 predpochtitel'nee. CHtoby pometit' lyuboj iz etih razdelov kak
zagruzochnyj, ispol'zujte utilitu fdisk.

Vo vremya zagruzki, zagruzchik QNX (opcional'no ustanavlivaemyj
utilitoj fdisk) pozvolyaet vybirat' v tablice razdelov v kachestve
zagruzochnogo drugoj razdel, ne yavlyayushchijsya zagruzochnym po umolchaniyu.

Vy mozhete ispol'zovat' utilitu fdisk dlya sozdaniya,
modifikacii ili udaleniya razdelov.

Tak kak QNX rassmatrivaet kazhdyj razdel na diske kak
blok-orientirovannyj fajl, to eto daet vozmozhnost' dostupa k sleduyushchemu:

 disku celikom, ignoriruya razdely, kak k blok-orientirovannomu
fajlu;

 otdel'nomu razdelu kak k blok-orientirovannomu fajlu; etot
blok-orientirovannyj fajl budet podmnozhestvom blok-orientirovannogo
fajla, kotoryj opredelyaet ves' disk.





Dva fizicheskih diska.  Pervyj soderzhit DOS, QNX i UNIX razdely.
Vtoroj disk imeet DOS i QNX razdely.


Opredelenie blok-orientirovannyj fajlov
Imena vseh blok-orientirovannyh fajlov pomeshchayutsya v derevo
prefiksov togo komp'yutera, na kotorom raspolozheny blok-orientirovannye
fajly (derevo prefiksov rassmatrivaetsya v glave "Prostranstvo imen
vvoda/vyvoda"). Kogda zapuskaetsya drajver kontrollera diskov, Menedzher
fajlovoj sistemy avtomaticheski registriruet prefiksy, kotorye opredelyayut
blok-orientirovannyj fajl dlya kazhdogo fizicheskogo diska, podklyuchennogo k
kontrolleru. Utilita mount ispol'zuetsya dlya togo, chtoby
zaregistrirovat' prefiks dlya blok-orientirovannogo fajla dlya kazhdogo
razdela na diske.

Pust', naprimer, u vas imeetsya standartnyj kontroller Western
Digital, k kotoromu podklyucheny dva diska. Na odnom diske vy hotite
smontirovat' razdel DOS, razdel QNX i razdel UNIX. Na drugom diske vy
hotite smontirovat' razdel DOS i razdel QNX.

Menedzher fajlovoj sistemy opredelit blok-orientirovannye fajly
/dev/hd0 i /dev/hd1 dlya dvuh diskov, podklyuchennyh k
kontrolleru.

Zatem vy ispol'zuete utilitu mount, chtoby opredelit'
blok-orientirovannyj fajl dlya kazhdogo razdela. Naprimer:

mount -p /dev/hd0  -p /dev/hd1
opredelit sleduyushchie blok-orientirovannye fajly:

Razdel OS:
Blok-orientirovannyj fajl:
Razdel DOS na diske hd0
/dev/hd0t4
Razdel QNX na diske hd0
/dev/hd0t77
Razdel UNIX na diske hd0
/dev/hd0t99
Razdel DOS na diske hd1
/dev/hd1t4
Razdel QNX na diske hd1
/dev/hd1t77

Zamet'te, chto oboznachenie tn ispol'zuetsya dlya oboznacheniya
razdelov na diske, ispol'zuemyh opredelennymi operacionnymi sistemami.
Naprimer, razdel DOS oboznachaetsya t4, razdel UNIX -
eto t99 i t.d.


Montirovanie fajlovoj sistemy
Obychno fajlovaya sistema QNX montiruetsya na blok-orientirovannom
fajle. Dlya etogo vy snova ispol'zuete utilitu mount - ona
pozvolyaet zadat' prefiks, kotoryj identificiruet fajlovuyu sistemu.
Naprimer:

mount /dev/hd0t77 /
montiruet fajlovuyu sistemu s prefiksom / na razdele, kotoryj
opredelen blok-orientirovannym fajlom s imenem hd0t77.





Esli disk razbit na razdely, to vy dolzhny smontirovat'
blok-orientirovannyj fajl dlya razdela QNX 4.x (naprimer /dev/hd0t77),
a ne osnovnoj blok-orientirovannyj fajl, kotoryj opredelyaet ves' disk
(naprimer, /dev/hd0). Esli vy popytaetes' smontirovat' osnovnoj
blok-orientirovannyj fajl dlya vsego diska, to pri popytke dostupa k
fajlovoj sisteme poluchite soobshchenie "corrupt filesystem" (povrezhdennaya
fajlovaya sistema).





Demontirovanie fajlovoj sistemy
CHtoby demontirovat' fajlovuyu sistemu, ispol'zujte utilitu umount.
Tak, naprimer, sleduyushchaya komanda demontiruet fajlovuyu sistemu na
pervichnom razdele QNX:

umount /dev/hd0t77
Posle togo, kak fajlovaya sistema demontirovana, fajly v etom
razdele uzhe ne dostupny.



Klyuchevye komponenty QNX razdela
V nachale kazhdogo razdela QNX raspolagayutsya sleduyushchie klyuchevye
komponenty:

 blok zagruzchika;
 kornevoj blok;
 bitovaya karta;
 kornevoj katalog.

|ti struktury sozdayutsya pri inicializacii fajlovoj sistemy
utilitoj dinit.





Struktura fajlovoj sistemy QNX vnutri razdela diska.



Blok zagruzchika
|to pervyj fizicheskij blok razdela diska. |tot blok soderzhit kod,
kotoryj zagruzhaetsya i zatem ispolnyaetsya BIOS komp'yutera dlya zagruzki
operacionnoj sistemy iz razdela. Esli disk ne razbit na razdely
(naprimer, gibkij disk), etot blok yavlyaetsya pervym fizicheskim blokom na
diske.


Kornevoj blok
Kornevoj blok imeet tu zhe strukturu, chto i obychnyj katalog. On
soderzhit informaciyu o chetyreh osobyh fajlah:

 kornevoj katalog fajlovoj sistemy (/)
 fajl /.inodes
 fajl /.boot
 fajl /.altboot


Fajly /.boot i /.altboot soderzhat obrazy operacionnoj
sistemy, kotorye zagruzhayutsya programmoj nachal'noj zagruzki QNX.

Obychno zagruzchik QNX zagruzhaet obraz OS, hranyashchijsya v fajle
/.boot. No esli fajl /.altboot ne pust, to vam budet
predlozhena opciya zagruzki obraza, hranyashchegosya v fajle /.altboot.


Bitovaya karta
CHtoby raspredelyat' prostranstvo na diske, QNX ispol'zuet bitovuyu
kartu, hranyashchuyusya v fajle /.bitmap. |tot fajl soderzhit
bitovuyu masku dlya vseh blokov na diske, pokazyvayushchuyu, kakie bloki zanyaty.
Kazhdomu bloku sootvetstvuet odin bit. Esli znachenie bita 1, to
sootvetstvuyushchij blok na diske zanyat.


Kornevoj katalog
Kornevoj katalog razdela vedet sebya kak obychnyj katalog, za
dvumya isklyucheniyami:

 kak ".", tak i ".." yavlyayutsya svyazyami k odnoj i toj zhe
inode informacii,  a imenno, kornevym katalogom inode v kornevom bloke;
 kornevoj katalog vsegda soderzhit elementy dlya fajlov
/.bitmap, /.inodes, /.boot i /.altboot.
|ti elementy predusmotreny dlya togo, chtoby programmy, kotorye vydayut
informaciyu o fajlovoj sisteme, videli eti elementy kak obychnye fajly.



Menedzher fajlovoj sistemy DOS
V QNX prostranstvo imen vvoda/vyvoda upravlyaetsya cherez prefiksy,
kotorye napravlyayut zaprosy sootvetstvuyushchim processam-menedzheram. Odnim
iz takih processov yavlyaetsya Menedzher fajlovoj sistemy DOS (Dosfsys).
Dosfsys registriruet prefiks /dos i predstavlyaet diski
DOS vnutri prostranstva imen QNX kak "gostevye" fajlovye sistemy.

Dosfsys obespechivaet prozrachnyj dostup k diskam DOS,
tak chto vy mozhete rassmatrivat' fajlovye sistemy DOS kak fajlovye
sistemy QNX. Takaya prozrachnost' pozvolyaet processam rabotat' s fajlami
DOS bez kakih-libo special'nyh znanij ili dejstvij. Standartnye bibliotechnye
funkcii vvoda/vyvoda, takie kak open(), close(), read()
i write() rabotayut s fajlom v razdele DOS tochno tak zhe, kak i s fajlom
v razdele QNX. Naprimer, chtoby kopirovat' fajl iz razdela QNX v razdel DOS,
dostatochno vypolnit' komandu:

cp /usr/luc/file.dat /dos/c/file.dat
Zamet'te, chto /dos/c - eto put' k DOS disku C.
Komanda cp ne soderzhit kakogo-libo special'nogo koda dlya
opredeleniya, nahoditsya li kopiruemyj fajl na diske DOS. Drugie komandy
rabotayut s takoj zhe prozrachnost'yu (naprimer, utility cd,
ls i mkdir).

Esli ne sushchestvuet ekvivalenta DOS dlya funkcii QNX, takoj kak
mkfifo() ili link(), to Dosfsys vozvrashchaet
sootvetstvuyushchij kod oshibki (t.e. errno).

Dosfsys rabotaet kak s gibkimi diskami, tak i s razdelami
zhestkih diskov. Ves' trebuemyj dostup k disku na nizkom urovne proizvoditsya
cherez standartnye funkcii Menedzhera fajlovoj sistemy. Poetomu,
bez dostupa k kodu nizkogo urovnya, Dosfsys sposoben obespechit'
prozrachnyj interfejs mezhdu prilozheniyami QNX i fajlovoj sistemoj DOS.



Fajlovaya sistema CD-ROM
Fajlovaya sistema CD-ROM, Iso9660fsys, obespechivaet prozrachnyj
dostup k nositelyam CD-ROM, takim obrazom mozhno rabotat' s fajlovymi
sistemami CD-ROM, kak budto eto fajlovye sistemy POSIX. Takaya
prozrachnost' obespechivaet processam dostup k fajlam na CD-ROM
standartnymi sredstvami.

Menedzher Iso9660fsys realizuet standart ISO 9660,
vklyuchaya rasshireniya Rock Ridge. |tomu standartu sootvetstvuyut
kompakt-diski DOS i Windows. V dopolnenie k obychnym fajlam,
Iso9660fsys takzhe podderzhivaet audio.



Fajlovaya sistema flesh
Menedzher fajlovoj sistemy flesh Efsys.*  byl special'no
razrabotan dlya raboty, kak so vstroennoj, tak i so smennoj flesh-pamyat'yu.
Fajly, zapisannye na smennye nositeli flesh (karty PC-Card), perenosimy v
drugie sistemy, kotorye takzhe podderzhivayut etot standart.

Menedzher Efsys.* sochetaet funkcii menedzhera fajlovoj
sistemy i drajvera ustrojstva. Tak kak Efsys.* soderzhit drajver
ustrojstva, to sushchestvuyut otdel'nye versii Efsys.* dlya razlichnyh
vidov oborudovaniya vstraivaemyh sistem. Naprimer:

Efsys.explr2 dlya platy Intel EXPLR2 (s RFA);
Efsys.elansc400 dlya platy AMD Elan SC400;
Efsys.pcmcia dlya smeshannogo ispol'zovaniya fajlovyh
sistem flesh i ustrojstv PCMCIA.

Ogranicheniya
Funkcional'nost' fajlovoj sistemy ogranichena ispol'zuemymi
ustrojstvami pamyati. Naprimer, dlya ustrojstv ROM fajlovaya sistema
dostupna tol'ko dlya chteniya.

Dlya ustrojstv flesh-pamyati sushchestvuyut ogranicheniya na zapis'
fajlov. Vy mozhete tol'ko dozapisyvat' fajl. Krome togo, ne obnovlyaetsya
vremya poslednego dostupa k fajlu. V nastoyashchij moment eti ogranicheniya
rasprostranyayutsya dazhe na SRAM ustrojstva.


Vosstanovlenie svobodnogo prostranstva
Menedzher Efsys.* hranit katalogi i fajly, ispol'zuya
svyaznye (svyaznye - imeyushchie pryamye/obratnye ukazateli) spiski struktur
dannyh, a ne bloki fiksirovannogo razmera, kak na diske, ispol'zuemye v
tradicionnyh fajlovyh sistemah s vrashchayushchimsya nositelem. Pri udalenii
kataloga ili fajla, prinadlezhashchie emu struktury dannyh pomechayutsya kak
udalennye, no ne stirayutsya, chtoby izbezhat' nepreryvnogo stiraniya i
perezapisi (i tem samym poter' vremeni na eti operacii).

So vremenem svobodnoe mesto zakonchitsya, i menedzheru fajlovoj
sistemy pridetsya vypolnit' vosstanovlenie svobodnogo prostranstva
(inogda etu operaciyu nazyvayut eshche "uborka musora").  Vo vremya etoj
procedury Efsys.* vosstanavlivaet svobodnoe mesto, zanimaemoe
udalennymi fajlami i katalogami. Dlya provedeniya etoj operacii
menedzheru fajlovoj sistemy trebuetsya hotya by odin svobodnyj blok.
Utilita mkffs avtomaticheski rezerviruet dlya etoj celi odin
blok pri sozdanii fajlovoj sistemy.


Szhatie i raspakovka
Menedzher Efsys.* podderzhivaet raspakovku, chto uvelichivaet
ob®em dannyh, kotoryj mozhet hranit'sya na nositele. Raspakovka vypolnyaetsya
menedzherom fajlovoj sistemy dlya prilozhenij prozrachno.

Dlya etogo fajly dolzhny byt', pered zapuskom utility mkffs,
predvaritel'no szhaty s pomoshch'yu utility bpe. Esli zhe kopirovat'
szhatyj fajl v uzhe sozdannuyu fajlovuyu sistemu flesh, to on ostanetsya
szhatym i pri chtenii.


Dostup k fajlam
Esli zapretit' rasshireniya POSIX, to vladel'cem fajlov vsegda
budet schitat'sya root, a bity rezhima vsegda budut ustanovleny v
rwx. Komandy chgrp, chmod i chown v
etom sluchae ne budut rabotat'.


Montirovanie
Mozhet proizvodit'sya tol'ko pri inicializacii razdelov ili pri
zapuske menedzhera fajlovoj sistemy.


Dostup na nizkom urovne
Pri zapuske Efsys.*, on sozdaet dlya kazhdogo ustrojstva pamyati
special'nyj fajl v kataloge /dev. V sisteme s dvumya ustrojstvami
pamyati Efsys.* sozdast fajly /dev/skt1 i /dev/skt2.
Special'nye ustrojstva ignoriruyut razbienie na razdely, pozvolyaya dostup k
nositelyam na nizkom urovne.

Dostup k razdelu, soderzhashchemu obraz fajlovoj sistemy, vozmozhen
tol'ko na nizkom urovne (kak k "syromu" ustrojstvu). Dlya kazhdogo takogo
razdela Efsys.* sozdaet special'nyj fajl vida
/dev/sktXimgY, gde X - eto nomer gnezda
(socket), a Y - nomer razdela na etom nositele.



Fajlovaya sistema NFS
Pervonachal'no razrabotannaya kompaniej Sun Microsystems, NFS
(Network File System - Setevaya Fajlovaya Sistema) yavlyaetsya TCP/IP
prilozheniem, kotoroe s teh por bylo realizovano na bol'shinstve DOS i
UNIX sistem. Ego realizaciya v QNX ne zamenima dlya prozrachnogo dostupa k
fajlovym sistemam drugih OS, podderzhivayushchih NFS.





QNX iznachal'no podderzhivaet setevye fajlovye sistemy. Ispol'zovat' NFS
neobhodimo tol'ko dlya dostupa k ne-QNX NFS fajlovym sistemam, libo
esli vy hotite otkryt' NFS-klientam dostup k fajlam QNX.





NFS pozvolyaet otobrazhat' udalennye fajlovye sistemy - polnost'yu
ili chastichno - v lokal'noe prostranstvo imen. Katalogi na udalennoj
sisteme vyglyadyat kak chast' lokal'noj fajlovoj sistemy, i vse utility
raboty s fajlami (ls, cp i mv) rabotayut s
udalennymi fajlami tak zhe, kak i s lokal'nymi.





V QNX 4 dlya NFS trebuetsya menedzher Socket, kotoryj podderzhivaet
setevye protokoly TCP/IP.  Zamet'te, chto ego "oblegchennyj" variant,
Socklet, mozhet ispol'zovat'sya, esli ne nuzhna NFS.






Fajlovaya sistema SMB
SMBfsys realizuet protokol SMB (Server Message Block)
sovmestnogo ispol'zovaniya fajlov, kotoryj ispol'zuetsya razlichnymi serverami,
takimi kak Windows NT, Windows 95, Windows for Workgroups, LAN Manager,
Samba. SMBfsys obespechivaet QNX-klientu prozrachnyj dostup k
udalennym diskam takih serverov.

SMBfsys realizuet etot protokol, ispol'zuya tol'ko
NetBIOS poverh TCP/IP, ne NetBEUI. Sootvetstvenno, neobhodimo,
chtoby TCP/IP byl ustanovlen, kak na QNX-mashine, tak i na udalennom servere.
Posle togo, kak zapushchen SMBfsys i smontirovan udalennyj server,
fajlovaya sistema servera poyavlyaetsya v lokal'nom dereve katalog.











Menedzher ustrojstv

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
obsluzhivanie ustrojstv;
rezhim redaktiruemogo vvoda;
rezhim neobrabatyvaemogo vvoda;
drajvery ustrojstv;
konsol' QNX;
posledovatel'nye ustrojstva;
parallel'nye ustrojstva;
proizvoditel'nost' podsistemy ustrojstv.


Vvedenie
Menedzher ustrojstv QNX (Dev) yavlyaetsya interfejsom mezhdu
processami i terminal'nymi ustrojstvami. |ti terminal'nye
ustrojstva raspolagayutsya v prostranstve imen vvoda/vyvoda s imenami,
nachinayushchimisya s /dev. Naprimer, konsol'noe ustrojstvo v QNX
budet imet' imya:

/dev/con1


Obsluzhivanie ustrojstv
Programmy v QNX poluchayut dostup k terminal'nym ustrojstvam, ispol'zuya
standartnye funkcii open(), close(), read() i
write(). Dlya processa QNX terminal'noe (okonechnoe) ustrojstvo
predstavlyaetsya dvunapravlennym potokom bajt, kotoryj mozhet schityvat'sya i
zapisyvat'sya processom.

Menedzher ustrojstv reguliruet potok dannyh mezhdu prilozheniem i
ustrojstvom. Dev vypolnyaet nekotoruyu obrabotku etih dannyh v
sootvetstvii s parametrami upravlyayushchej struktury terminala
(nazyvaemoj termios), kotoraya sushchestvuet dlya kazhdogo ustrojstva.
Pol'zovateli mogut zaprashivat' i/ili izmenyat' eti parametry s pomoshch'yu
utility stty; programmy mogut ispol'zovat' funkcii
tcgetattr() i tcsetattr().

Parametry struktury termios upravlyayut funkcional'nost'yu
nizkogo urovnya, takoj kak:

 parametry linii (vklyuchaya skorost' peredachi, kontrol' chetnosti,
stop-bity, bity dannyh);

 eho-vyvod simvolov;

 redaktirovanie stroki vvoda;

 raspoznavanie i reakciya na komandu "Break" i zavisaniya;

 programmnoe i apparatnoe upravlenie potokom dannyh;

 preobrazovanie vyvodimyh simvolov.

 
Menedzher ustrojstv takzhe predostavlyaet nabor dopolnitel'nyh
uslug, dostupnyh processam dlya raboty s terminal'nym ustrojstvom.  V
sleduyushchej tablice privedeny nekotorye iz etih uslug.


Process mozhet:
Funkciya Si:
Vypolnyat' operacii chteniya s kontrolem vremeni
dev_read() ili read() i tcsetattr()
Poluchat' asinhronnoe izveshchenie o dostupnyh
dannyh 
dev_arm()
Na odnom ili bolee ustrojstvah vvoda zhdat'
polnogo zaversheniya operacii vyvoda
tcdrain()
Posylat' komandu Break po kanalu svyazi 
tcsendbreak()
Razorvat' soedinenie
tcdropline()
Vstavit' vhodnye dannye 
dev_insert_chars()
Vypolnyat' neblokiruyushchiesya chtenie i zapis'
open() i fcntl() (O_NONBLOCK mode)

Rezhim redaktiruemogo vvoda
Naibolee vazhnyj rezhim raboty ustrojstva upravlyaetsya bitom ICANON
v upravlyayushchej strukture termios. Esli etot upravlyayushchij bit
ustanovlen, to Menedzher ustrojstv vypolnyaet funkcii redaktirovaniya
stroki dlya prinimaemyh simvolov. Takim obrazom, tol'ko kogda stroka
"vvedena" - obychno, kogda poluchen simvol perevoda karetki (CR), -
dannye stanut dostupny dlya prikladnyh processov. Takoj rezhim raboty
nazyvaetsya redaktiruemym - ot anglijskogo edited.
|tot rezhim eshche nazyvayut canonical (kanonicheskim)
i inogda cooked (prigotovitel'nym).

Bol'shinstvo nepolnoekrannyh prilozhenij vypolnyayutsya v redaktiruemom
rezhime. Tipichnym primerom yavlyaetsya komandnyj interpretator (Shell).

Sleduyushchaya tablica pokazyvaet, kak Dev obrabatyvaet nekotorye
special'nye upravlyayushchie simvoly, esli sootvetstvuyushchie parametry
ustanovleny v strukture termios.


Dev vypolnit:
Kogda poluchit simvol:
Sdvig kursora na odin simvol vlevo
LEFT
Sdvig kursora na odin simvol vpravo
RIGHT
Sdvig kursora v nachalo stroki
HOME
Sdvig kursora v konec stroki
END
Udalenie simvola sleva ot kursora
ERASE
Udalenie simvola v tekushchej pozicii kursora
DEL
Udalenie vsej stroki vvoda
KILL
Stiranie tekushchej stroki i vosstanovlenie predydushchej
UP
Stiranie tekushchej stroki i vosstanovlenie sleduyushchej
DOWN
Pereklyuchenie mezhdu rezhimami vstavki i zameny
INS

Simvoly redaktirovaniya stroki otlichayutsya dlya razlichnyh
terminalov.  Pri zapuske konsoli QNX vsegda opredelen polnyj nabor
redaktiruyushchih simvolov.

Esli terminal podklyuchen k QNX cherez posledovatel'nyj kanal,
neobhodimo ustanovit' redaktiruyushchie simvoly, kotorye budut
ispol'zovat'sya dlya dannogo konkretnogo terminala. Dlya etogo vy mozhete
ispol'zovat' utilitu stty.  Naprimer, esli terminal VT100
podklyuchen k posledovatel'nomu portu (/dev/ser1), to sleduyushchaya
komanda izvlechet sootvetstvuyushchie redaktiruyushchie simvoly iz bazy dannyh
terminfo i primenit ih k /dev/ser1:

 
stty term=vt100 </dev/ser1
Esli zhe k etomu posledovatel'nomu portu podklyuchen modem, dlya
svyazi s drugoj QNX sistemoj s pomoshch'yu utility qtalk,
redaktiruyushchie simvoly sleduet ustanovit' tak:

stty term=qnx </dev/ser1


Rezhim neobrabatyvaemogo vvoda
Kogda bit ICANON ne ustanovlen, to govoryat, chto ustrojstvo nahoditsya v
neobrabatyvaemom ("syrom", anglijskij termin raw)
rezhime. V etom rezhime ne proizvoditsya nikakoe redaktirovanie vvoda, a vse
poluchaemye dannye nemedlenno stanovyatsya dostupnymi dlya QNX-processov.

Polnoekrannye programmy i kommunikacionnye programmy yavlyayutsya
primerami prilozhenij, kotorye perevodyat ustrojstvo v syroj rezhim.

Pri chtenii iz syrogo ustrojstva prilozhenie mozhet zadat'
usloviya, pri kotoryh budet udovletvoren zapros na vvod dannyh.
Kriterii, ispol'zuemye pri prieme syryh dannyh, baziruyutsya na
dvuh parametrah struktury termios: MIN i TIME. Prilozhenie mozhet
opredelit' eshche odin dopolnitel'nyj parametr pri vyzove funkcii
dev_read(). |tot parametr, TIMEOUT, ispol'zuetsya pri napisanii
protokolov ili prilozhenij real'nogo  vremeni. Uchtite, chto dlya  funkcii
read() TIMEOUT vsegda 0.

Kogda process zaprashivaet vvod n bajt dannyh, eti tri
parametra opredelyayut, kogda dolzhen byt' udovletvoren zapros:


MIN
TIME
TIMEOUT
Opisanie:
0
0
0
Vernut' nemedlenno stol'ko bajt, skol'ko
dostupno v dannyj moment (no ne bolee n bajt)
M
0
0
Vernut' ne bolee n bajt tol'ko togda, kogda
dostupny, po men'shej mere, M bajt
0
T
0
Vernut' ne bolee n bajt tol'ko togda, kogda dostupen hotya
by odin bajt libo isteklo T x .1 sekund.
M
T
0
Vernut' ne bolee n bajt tol'ko togda, libo kogda
budut dostupny M bajt, libo budet prinyat hotya by odin
bajt i interval mezhdu lyubymi posledovatel'no
prinyatymi simvolami prevysil T x .1 sekund.
0
0
t
Zarezervirovano.
M
0
t
Vernut' ne bolee n bajt tol'ko togda, kogda
dostupny M bajt libo isteklo t x .1 sekund.
0
T
t
Zarezervirovano.
M
T
t
Vernut' ne bolee n bajt tol'ko togda, kogda dostupny M
bajt, libo isteklo t x .1 sekund i ne byl poluchen ni odin simvol,
libo byl prinyat hotya by odin bajt i interval mezhdu lyubymi posledovatel'no
prinyatymi simvolami prevysil T x .1 sekund.

Drajvery ustrojstv
Na risunke pokazana tipichnaya podsistema ustrojstv v QNX.




Menedzher ustrojstv (Dev) organizuet obmen dannymi mezhdu
ustrojstvami i prikladnymi programmami. Apparatnyj interfejs upravlyaetsya
individual'nymi processami drajverami. Dev, dlya kazhdogo
iz ustrojstv, obmenivaetsya dannymi s drajverami cherez
ocheredi v razdelyaemoj pamyati.





Ispol'zovanie razdelyaemoj pamyati trebuet, chtoby Dev i
drajvery nahodilis' na odnom i tom zhe fizicheskom komp'yutere,
preimushchestvom zhe yavlyaetsya povyshennaya proizvoditel'nost'.



Dlya kazhdogo terminal'nogo ustrojstva ispol'zuyutsya tri
ocheredi. Kazhdaya ochered' realizovana na osnove mehanizma "pervyj voshel
- pervyj vyshel". Kazhdoj  ocheredi takzhe sootvetstvuet svoya  upravlyayushchaya
struktura.

Prinimaemye dannye pomeshchayutsya drajverom v ochered' syrogo vvoda, i
Dev izvlekaet ih, tol'ko kogda prikladnye programmy
zaprashivayut dannye.  Obrabotchiki preryvanij vnutri drajverov obychno
vyzyvayut proverennuyu bibliotechnuyu proceduru vnutri Dev dlya
dobavleniya dannyh v etu ochered' - eto obespechivaet edinoobraznyj
poryadok vvoda i sushchestvenno minimiziruet otvetstvennost' drajvera.

Dev pomeshchaet vyvodimye dannye v ochered' vyvoda; dannye
izvlekayutsya drajverom po mere togo, kak simvoly fizicheski peredayutsya
ustrojstvu. Dev vyzyvaet proverennuyu proceduru vnutri
drajvera kazhdyj raz, kogda dobavlyayutsya novye dannye, takim obrazom on
"podtalkivaet" drajver k rabote (v sluchae, esli on ne byl zanyat).
Blagodarya ispol'zovaniyu ocheredej vyvoda Dev realizuet
buferizovannuyu zapis' (write-behind) dlya vseh terminal'nyh
ustrojstv. Tol'ko kogda bufery vyvoda zapolneny, Dev vyzyvaet
blokirovanie processa pri zapisi.

Redaktiruemaya ochered' polnost'yu upravlyaetsya Dev i
ispol'zuetsya pri vvode dannyh v redaktiruemom rezhime. Razmer etoj
ocheredi opredelyaet maksimal'nyj razmer stroki redaktiruemogo vvoda
dlya konkretnogo ustrojstva.

Razmery vseh etih ocheredej mogut konfigurirovat'sya sistemnym
administratorom; edinstvennoe ogranichenie sostoit v tom, chto obshchij
summarnyj razmer vseh treh ocheredej ne mozhet prevyshat' 64K. Znachenij
po umolchaniyu obychno bolee chem dostatochno dlya bol'shinstva apparatnyh
konfiguracij, no vy mozhete "nastraivat'" ih, libo dlya umen'sheniya obshchej
potrebnosti sistemy v pamyati, libo v sluchae nestandartnyh apparatnyh
konfiguracij.


Upravlenie ustrojstvami
Drajvery ustrojstv prosto dobavlyayut poluchaemye dannye v ochered'
syrogo vvoda ili izvlekayut i peredayut dannye iz ocheredi vyvoda.
Dev reshaet, kogda vyvod dolzhen byt' priostanovlen, dolzhno li
byt' "eho" prinimaemyh dannyh i t.d.

CHtoby obespechit' horoshuyu reakciyu na vhodnye sobytiya, Dev
dolzhen vypolnyat'sya s dostatochno vysokim prioritetom. Dev
obychno malo zagruzhen rabotoj, poetomu on redko snizhaet obshchuyu
proizvoditel'nost' sistemy. Sami drajvery, kak i lyubye drugie
processy v QNX, mogut vypolnyat'sya s razlichnymi prioritetami v
zavisimosti ot haraktera obsluzhivaemyh ustrojstv.

Sami drajvery, kak i lyubye drugie
processy v QNX, mogut vypolnyat'sya s razlichnymi prioritetami v
zavisimosti ot haraktera obsluzhivaemyh ustrojstv.

Upravlenie ustrojstvami na nizkom urovne vypolnyaetsya cherez
dal'nij vyzov vhodnoj tochki ioctl vnutri kazhdogo drajvera.  Obshchij
nabor ioctl komand podderzhivaetsya neposredstvenno Dev.
Specificheskie dlya ustrojstva ioctl komandy mogut byt' poslany QNX
processami drajveru cherez funkciyu Si qnx_ioctl().



Konsol' QNX
Sistemnye konsoli podderzhivayutsya drajverom Dev.con.
|kran, adapter displeya i sistemnaya klaviatura - vmeste nazyvayutsya
konsol'yu.

QNX pozvolyaet parallel'noe vypolnenie mnozhestva sessij na
konsolyah posredstvom virtual'nyh konsolej.  Drajver
Dev.con obychno podderzhivaet bolee odnogo nabora ocheredej
vvoda/vyvoda k Dev, kotorye dostupny pol'zovatel'skim
processam kak mnozhestvo terminal'nyh ustrojstv s imenami vida
/dev/con1, /dev/con2 i t.d. S tochki zreniya
prilozheniya, eto "nastoyashchie" dostupnye konsoli.

Konechno, sushchestvuet tol'ko odin fizicheskij ekran i
klaviatura, i poetomu tol'ko odna iz etih virtual'nyh konsolej
dejstvitel'no pokazyvaetsya v kazhdyj moment vremeni. Klaviatura
"podklyuchena" k toj virtual'noj konsoli, kotoraya vidima v tekushchij moment.

Funkcii, specifichnye dlya konsoli
V dopolnenie k realizacii standartnogo terminala QNX (opisan v
Rukovodstve pol'zovatelya), drajver konsoli takzhe obespechivaet
nabor specificheskih dlya konsoli funkcij, kotorye pozvolyayut
prilozheniyam neposredstvenno vzaimodejstvovat' s drajverom konsoli
putem obmena soobshcheniyami.  Svyaz' ustanavlivaetsya vyzovom funkcii Si
console_open(). Posle togo kak svyaz' ustanovlena, process imeet
dostup k sleduyushchim vozmozhnostyam:


Process mozhet:
CHerez funkciyu Si:

CHitat' neposredstvenno s ekrana konsoli
console_read()
Pisat' neposredstvenno na ekran konsoli
console_write()
Poluchat' asinhronnoe izveshchenie o vazhnyh
sobytiyah (naprimer, izmenenie polozheniya kursora,
razmera displeya, pereklyuchenie konsoli i t.d.)
console_arm()
Upravlyat' razmerami konsoli
console_size()
Pereklyuchat' vidimuyu konsol'
console_active()

Drajver konsoli QNX vypolnyaetsya kak normal'nyj process QNX.
Vvodimye s klaviatury simvoly pomeshchayutsya obrabotchikom preryvaniya
klaviatury neposredstvenno v ochered' vvoda.  Vyvodimye dannye
otobrazhayutsya Dev.con v to vremya, kogda on vypolnyaetsya kak
process.


Posledovatel'nye ustrojstva
Posledovatel'nye kanaly svyazi obsluzhivayutsya drajverom
Dev.ser. |tot drajver mozhet obsluzhivat' bolee odnogo
fizicheskogo kanala; on obespechivaet terminal'nye ustrojstva s imenami
vida /dev/ser1, /dev/ser2 i t.d.

Pri zapuske Dev.ser vy mozhete zadat' argumenty komandnoj
stroki, kotorye opredelyayut, kakie - i skol'ko - posledovatel'nye
porty ustanovleny. CHtoby uvidet' dostupnye posledovatel'nye porty,
ispol'zujte utilitu ls:

ls /dev/ser*
Dev.ser yavlyaetsya primerom upravlyaemogo preryvaniyami servera
vvoda/vyvoda. Posle inicializacii oborudovaniya sam process perehodit
v sostoyanie ozhidaniya ("zasypaet"). Preryvaniya pomeshchayut vhodnye dannye
neposredstvenno v ochered' vvoda. Pervyj vyvodimyj simvol peredaetsya
ustrojstvu, kogda Dev "podtalkivaet" drajver. Posleduyushchie
simvoly peredayutsya pri obrabotke sootvetstvuyushchego preryvaniya.



Parallel'nye ustrojstva
Parallel'nye porty printera obsluzhivayutsya drajverom Dev.par.
Pri zapuske Dev.par vy mozhete zadat' argument komandnoj stroki,
kotoryj opredelyaet, kakoj posledovatel'nyj port ustanovlen. CHtoby uvidet',
dostupen li posledovatel'nyj port, ispol'zujte utilitu ls:

ls /dev/par*
Dev.par yavlyaetsya tol'ko vyvodyashchim drajverom, poetomu u
nego net ocheredej vvoda.  Vy mozhete konfigurirovat' razmer bufera
vyvoda s pomoshch'yu argumentov komandnoj stroki pri zapuske
Dev.par. Bufer vyvoda mozhet byt' sdelan ochen' bol'shim, esli
vy hotite obespechit' programmnyj bufer pechati.

Dev.par yavlyaetsya primerom servera vvoda/vyvoda, ne
ispol'zuyushchim preryvaniya. |tot process normal'no nahoditsya v sostoyanii
RECEIVE-blokirovan, ozhidaya poyavleniya dannyh v ocheredi vyvoda i
"tolchka" ot Dev. Kogda dostupny dannye dlya vyvoda na pechat',
Dev.par vypolnyaetsya v cikle rabota-ozhidanie (s otnositel'no
nizkim adaptivnym prioritetom), ozhidaya, kogda simvoly budut prinyaty
printerom. Takoj nizkoprioritetnyj cikl rabota-ozhidanie ne vliyaet na
obshchuyu proizvoditel'nost' sistemy i, v to zhe vremya, dostigaet
maksimal'no vozmozhnuyu propusknuyu sposobnost' k parallel'nomu
ustrojstvu.



Proizvoditel'nost' podsistemy ustrojstv
Potok sobytij vnutri podsistemy ustrojstv skonstruirovan tak,
chtoby minimizirovat' izbytochnost' i dostich' maksimal'noj propusknoj
sposobnosti, kogda ustrojstvo rabotaet v syrom rezhime. S etoj
cel'yu ispol'zuyutsya sleduyushchie pravila:

 Obrabotchiki preryvanij pomeshchayut prinyatye dannye neposredstvenno v
ocheredi v pamyati. Tol'ko pri nalichii zhdushchego zaprosa na chtenie i
pri uslovii, chto etot zapros mozhet byt' udovletvoren, obrabotchik preryvaniya
iniciiruet vypolnenie Dev. Vo vseh ostal'nyh sluchayah vypolnyaetsya
prosto vozvrat iz preryvaniya. Bolee togo, esli Dev uzhe vypolnyaetsya,
to nikakoj dispetcherizacii ne proizvoditsya.

 Kogda zapros na chtenie udovletvoren, Dev kopiruet dannye v
prilozhenie neposredstvenno iz bufera syrogo vvoda. Kak
rezul'tat, dannye kopiruyutsya tol'ko odin raz.
|ti pravila - v sochetanii s isklyuchitel'no malen'kimi zaderzhkami
preryvaniya i dispetcherizacii v QNX - obespechivayut ochen' effektivnuyu
model' vvoda.









Menedzher seti

|ta glava ohvatyvaet sleduyushchie temy:
vvedenie;
obyazannosti Menedzhera seti;
interfejs Mikroyadro/Menedzher seti;
setevye drajvery;
identifikatory uzla i seti;
vybor seti;
set' TCP/IP.


Vvedenie
Menedzher seti (Net) daet pol'zovatelyam QNX prozrachnoe
rasshirenie moshchnyh vozmozhnostej mehanizma peredachi soobshchenij.
Vzaimodejstvuya neposredstvenno s Mikroyadrom, Menedzher seti usilivaet
mehanizm IPC na osnove obmena soobshcheniyami, peredavaya soobshcheniya na
udalennye komp'yutery. Krome togo, Menedzher seti obespechivaet:

 povyshennuyu propusknuyu sposobnost' za schet balansirovki nagruzki;

 otkazoustojchivost' za schet rezervirovaniya soedinenij;

 funkcii mosta mezhdu QNX setyami.

 

Obyazannosti Menedzhera seti
Menedzher seti otvechaet za rasprostranenie primitivov peredachi
soobshchenij QNX v predelah lokal'noj seti. Standartnye primitivy peredachi
soobshchenij ispol'zuyutsya bez izmeneniya dlya svyazi s udalennym
komp'yuterom. Drugimi slovami, ne sushchestvuet osobyh "setevyh" Send(),
Receive() ili Reply().


Nezavisimyj modul'
Menedzher seti ne dolzhen byt' obyazatel'no vstroen v obraz
operacionnoj sistemy.  On mozhet byt' zapushchen i ostanovlen v lyuboe
vremya, chtoby obespechit' ili udalit' setevye vozmozhnosti peredachi
soobshchenij.

Pri zapuske Menedzher seti registriruetsya u Menedzhera processov i
YAdra. |to aktiviziruet kod vnutri poslednih, kotoryj vzaimodejstvuet
s Menedzherom seti. |to oznachaet, chto peredacha soobshchenij po seti i
sozdanie udalennyh processov - eto ne prosto dobavlyaemyj poverh
operacionnoj sistemy sloj.  Setevye vozmozhnosti integrirovany v samuyu
serdcevinu primitivov peredachi soobshchenij i upravleniya processami.

Takaya glubokaya integraciya na samom nizhnem urovne obespechivaet
QNX setevuyu prozrachnost' i delaet ee polnost'yu raspredelennoj
operacionnoj sistemoj.  Poskol'ku prilozheniya zaprashivayut i poluchayut dostup
ko vsem obsluzhivayushchim programmam posredstvom soobshchenij i Menedzher seti
obespechivaet prozrachnoe prohozhdenie soobshchenij po seti, to uzly QNX
funkcioniruyut vmeste kak edinyj logicheskij komp'yuter.

Poskol'ku Menedzher seti i Mikroyadro otdeleny drug ot druga,
Mikroyadro mozhet dostich' nezavisimosti ot setevogo oborudovaniya, a
komp'yutery, ne podklyuchennye k seti, mogut vyigrat' za schet men'shego
ob®ema koda.



Interfejs Mikroyadro/Menedzher seti
Mikroyadro i Menedzher processov vzaimodejstvuyut s Menedzherom seti
cherez special'nuyu neblokiruyushchuyu ochered' v pamyati. |ta ochered' predstavlyaet
soboj spisok peredach, kotorye dolzhen vypolnit' Menedzher seti. |lementy
ocheredi soderzhat vsyu informaciyu o konkretnoj operacii (naprimer,
Send(), Reply(), sozdanie virtual'nogo kanala (VC), peredacha
udalennogo signala i t.d.).

Drugim resursom operacionnoj sistemy, ispol'zuemym dlya obespecheniya
prozrachnoj peredachi soobshchenij, yavlyaetsya bufer virtual'nogo kanala.
Vydelyaemyj pri sozdanii VC processom, bufer virtual'nogo kanala hranit
dannye do zaversheniya operacii peredachi soobshcheniya na drugoj uzel.

Nizhe privedeny diagrammy, illyustriruyushchie process posylki i
priema udalennyh soobshchenij.


Posylka soobshcheniya na udalennyj uzel




Process vyzyvaet Send() ili Reply() k udalennomu uzlu.



V sluchae vyzova Send() ili Reply() k udalennomu uzlu,
imeyut mesto sleduyushchie sobytiya:



Process vyzyvaet Send() ili Reply(), i Mikroyadro
kopiruet dannye iz oblasti dannyh processa v bufer virtual'nogo
kanala.
Mikroyadro dobavlyaet v ochered' Menedzhera seti element,
soderzhashchij identifikatory otpravitelya, udalennogo poluchatelya i
ukazatel' na dannye v bufere virtual'nogo kanala. Esli pered etim
ochered' byla pusta, to Menedzher seti poluchaet proksi, izveshchayushchee o
tom, chto poyavilas' novaya rabota.
Menedzher seti izvlekaet element iz ocheredi.
Menedzher seti posylaet element sootvetstvuyushchemu setevomu
drajveru.
Menedzher seti nachinaet peredachu dannyh po seti i otvechaet za
dostavku.


V sluchae rasprostraneniya signala ili sozdaniya VC, Menedzher
processov, a ne Mikroyadro, dobavlyaet upravlyayushchij paket v ochered' .
Kak i v predydushchem sluchae, Menedzher seti peredast paket po
naznacheniyu.

Poluchenie soobshcheniya s udalennogo uzla




Process poluchaet udalennyj Send() ili Reply().



Dopustim, chto udalennyj uzel poslal soobshchenie, kak opisano vyshe.
V etom sluchae na prinimayushchem uzle imeyut mesto sleduyushchie sobytiya:



Setevoj drajver pomeshchaet postupivshie po seti dannye v
sootvetstvuyushchij bufer virtual'nogo kanala.
Setevoj drajver informiruet Menedzher seti o tom, chto priem
zavershen.
Menedzher seti ispol'zuet chastnyj vyzov YAdra, izveshchaya ego o
tom, chto priem zavershen.
Mikroyadro kopiruet dannye iz bufera virtual'nogo kanala v
bufer processa (pri uslovii, chto on RECEIVE- ili REPLY-blokirovan na
etom virtual'nom kanale).

Lyubye upravlyayushchie pakety, kotorye poluchaet Menedzher seti,
nemedlenno perepravlyayutsya Menedzheru processov cherez standartnyj
primitiv Send().  |ti upravlyayushchie pakety ispol'zuyutsya dlya
rasprostraneniya signalov i sozdaniya virtual'nyh kanalov.


Setevye drajvery
Podobno Menedzheru fajlovoj sistemy i Menedzheru ustrojstv,
Menedzher seti ne soderzhit apparatno-zavisimogo koda.  |ta
funkcional'nost' obespechivaetsya drajverami setevyh plat.  Menedzher
seti mozhet podderzhivat' odnovremenno neskol'ko setevyh drajverov.
Kazhdyj drajver obychno obsluzhivaet odnu setevuyu platu. Vy mozhete imet'
drajvery/platy odnogo i togo zhe tipa ili razlichnyh tipov - naprimer,
dva drajvera/platy Ethernet ili, dopustim, drajver/platu Ethernet i
drajver/platu Arcnet.

Interfejs mezhdu Menedzherom seti i drajverami realizovan cherez
ocheredi v razdelyaemoj pamyati.  |tot interfejs razrabotan takim
obrazom, chtoby dostich' maksimal'no vozmozhnoj proizvoditel'nosti.
Drajver opredelyaet protokol, podhodyashchij dlya dannogo setevogo
nositelya.

Drajver otvechaet za formirovanie paketov, organizaciyu
posledovatel'nosti i v sluchae, kogda trebuetsya garantirovannaya dostavka
dannyh udalennomu uzlu, povtornuyu peredachu. Takaya arhitektura pozvolyaet QNX
legko podderzhivat' novoe setevoe oborudovanie i protokoly za schet
napisaniya ili modifikacii tol'ko setevogo drajvera.



Identifikatory uzla i seti
Kazhdyj uzel v lokal'noj seti identificiruetsya
dvumya chislami:
fizicheskim identifikatorom (ID) uzla (ili identifikatorami,
esli uzel imeet bolee odnoj setevoj platy);
kombinaciej logicheskogo ID uzla i logicheskogo ID seti.


Fizicheskij ID uzla
Fizicheskij ID uzla opredelyaetsya oborudovaniem.  Setevye platy
obmenivayutsya dannymi drug s drugom, ukazyvaya fizicheskij ID udalennogo
uzla, s kotorym dolzhna byt' ustanovlena svyaz'. V sluchae seti Ethernet
ili Token Ring - eto bol'shoe chislo, kotorym neudobno operirovat'
lyudyam i utilitam.  Naprimer, kazhdaya plata Ethernet ili Token Ring
imeet unikal'nyj 48-bitnyj fizicheskij ID uzla v sootvetstvii so
standartom IEEE 802.  Platy Arcnet, naprotiv, imeyut vsego lish'
8-bitnyj ID.

Ispol'zovanie fizicheskogo ID uzla imeet sushchestvennyj nedostatok:
pri soedinenii nekotoryh setej mozhet vozniknut' konflikt adresov
(osobenno v sluchae Arcnet), ili format adresov mozhet radikal'no
otlichat'sya.


Logicheskij ID uzla
CHtoby obojti nazvannye vyshe problemy, voznikayushchie pri
ispol'zovanii fizicheskih ID uzlov, kazhdomu uzlu QNX prisvaivaetsya
logicheskij ID uzla. Vse processy QNX operiruyut logicheskimi ID
uzlov. Fizicheskie ID uzlov skryty ot processov, vypolnyayushchihsya v QNX.

Ispol'zovanie logicheskih ID uzlov uproshchaet licenzirovanie.  Takzhe
oni pozvolyayut utilitam, kotorye oprashivayut set', ispol'zovat' prostoj
cikl, v kotorom logicheskij ID uzla izmenyaetsya ot 1 do kolichestva
uzlov.

Sootvetstvie mezhdu logicheskimi i fizicheskimi ID uzlov
ustanavlivaetsya Menedzherom seti.  Menedzher seti, kogda poruchaet
drajveru peredat' dannye na drugoj uzel, peredaet emu fizicheskij ID
etogo uzla.

Logicheskie ID uzlov obychno prisvaivayutsya po poryadku,
nachinaya s 1.  Naprimer, uzel, imeyushchij platu Ethernet, mozhet poluchit'
logicheskij ID 2, kotoryj budet sootvetstvovat' fizicheskomu ID
uzla 00:00:c0:46:93:30.

Logicheskie ID uzlov dolzhny byt' unikal'ny dlya vseh uzlov vo vseh
soedinennyh QNX-setyah, chtoby sdelat' vozmozhnym funkcionirovanie mostov.


Logicheskij ID seti
ID seti identificiruet konkretnuyu logicheskuyu set'. Logicheskaya
set' - eto lyuboe oborudovanie, kotoroe pozvolyaet setevomu drajveru
neposredstvenno vzaimodejstvovat' s setevym drajverom na drugom uzle.
|to mozhet byt' kak prosto posledovatel'nyj port, tak i slozhnaya set'
Ethernet s apparatnymi mostami.

Na sleduyushchej diagramme uzel 7 imeet dve setevye platy, kotorye
pozvolyayut emu imet' dostup k uzlam v logicheskih setyah 1 i 2. Uzly 8 i
9 imeyut po tri platy, podklyuchayushchie ih k setyam 1, 2 i 3.

Zamet'te, chto vse logicheskie ID uzlov unikal'ny dlya vseh treh
logicheskih uzlov.





Logicheskie ID uzlov seti naznachayutsya sistemnym administratorom. Bolee
podrobno sm. v glave "Ustanovka seti" v knige Rukovodstve
pol'zovatelya.







Neskol'ko fizicheskih setej sosushchestvuyut posredstvom logicheskih setej.




Vybor seti
V sluchae, kogda uzly soedineny bolee chem odnoj logicheskoj set'yu,
Menedzher seti mozhet vybirat', kakuyu iz setej ispol'zovat' dlya
peredachi k udalennomu uzlu.  Naprimer, na privedennom vyshe risunke
uzel 7 mozhet peredavat' dannomu uzlu 8, ispol'zuya libo set' 1, libo
set' 2.


Raspredelenie nagruzki
Propusknaya sposobnost' seti opredelyaetsya sovokupnost'yu skorosti
komp'yutera i skorosti seti.  Esli komp'yuter mozhet vydavat' dannye
bystree, chem set' mozhet ih peredavat', to set' budet ogranichivat'
propusknuyu sposobnost'.

Naprimer, dva komp'yutera Pentium, soedinennye set'yu 10BASE-T
Ethernet, budut ogranicheny 1.1 millionom bajt v sekundu, to est'
skorost'yu peredachi dannyh, obespechivaemoj setevym oborudovaniem.
Odnako esli pomestit' po dve platy Ethernet v kazhdyj iz komp'yuterov
i soedinit' ih otdel'nymi kabelyami, to Menedzher seti smozhet
peredavat' dannye po obeim setyam odnovremenno.  Pri bol'shoj nagruzke
eto obespechit uvelichenie propusknoj sposobnosti v dva raza po
sravneniyu s odnoj set'yu.

Menedzher seti budet pytat'sya sbalansirovat' nagruzku, vybiraya
setevoj drajver.  V rassmotrennom vyshe primere, esli proizvoditsya
peredacha s uzla 7 na uzel 8 po seti 1 i drugaya peredacha na uzel 8
iniciiruetsya na uzle 7, to set' 2 budet avtomaticheski vybrana dlya
peredachi dannyh.

Otkazoustojchivost'
Kogda uzly soedineny dvumya i bolee setyami, to sushchestvuet bol'she
chem odin vozmozhnyj put' dlya svyazi. V sluchae otkaza platy v odnoj iz
setej, kogda svyaz' po etoj seti nevozmozhna, Menedzher seti
avtomaticheski perenapravit vse dannye cherez druguyu set'.  |to
proishodit na letu bez kakogo-libo vmeshatel'stva so storony
prikladnyh programm i obespechivaet prozrachnuyu otkazoustojchivost'
seti. Esli kabeli razlichnyh setej prolozheny razdel'no, to vy takzhe
budete zashchishcheny ot sluchajnogo obryva kabelya.

Vy takzhe mozhete proektirovat' sistemy-"tandemy", v kotoryh dve
mashiny soedineny vysokoskorostnoj set'yu dlya normal'noj raboty i
drugoj, bolee deshevoj i medlennoj set'yu (naprimer, po
posledovatel'nomu kanalu), kotoraya sluzhit rezervom. V sluchae otkaza
pervoj seti soedinenie ne oborvetsya, hotya propusknaya sposobnost',
konechno zhe, snizitsya.


Mosty mezhdu setyami QNX
Menedzher seti pozvolyaet lyubomu uzlu igrat' rol' mosta mezhdu
dvumya otdel'nymi setyami QNX, baziruyushchimisya na standarte IEEE 802.





Tak kak QNX ispol'zuet odinakovyj format paketov i protokol na vseh
IEEE 802 setyah, mozhno sozdavat' mosty mezhdu setyami Ethernet, Token
Ring i FDDI.
Dlya setej Arcnet nel'zya sozdavat' mosty.



Rassmotrim sleduyushchuyu diagrammu, gde odnoj seti prinadlezhat uzly
17 i 18, a drugoj - uzly 18 i 19:







Most mezhdu dvumya IEEE 802 QNX setyami.



Uzly 17 i 18 nahodyatsya v odnoj seti, poetomu oni mogut obshchat'sya
drug s drugom napryamuyu.  To zhe spravedlivo dlya uzlov 18 i 19.  No kak
mogut obshchat'sya uzly 17 i 19?

Tak kak obe lokal'nye seti baziruyutsya na IEEE 802, uzel 18
avtomaticheski perenapravlyaet pakety, pozvolyaya uzlam 17 i 18 sozdat'
virtual'nyj kanal.  Hotya oni i ne podklyucheny k odnoj i toj zhe
lokal'noj seti, uzly 17 i 19, tem ne menee, mogut obshchat'sya drug s
drugom.



Set' TCP/IP
Prisushchaya QNX podderzhka seti realizuet lokal'nuyu set' na osnove
sobstvennogo chastnogo protokola i optimizirovana dlya organizacii
interfejsa mezhdu QNX komp'yuterami. No dlya svyazi s ne-QNX sistemami,
QNX ispol'zuet stavshij promyshlennym standartom nabor protokolov,
nazyvaemyj TCP/IP.

Po mere togo kak Internet stal zanimat' vse bol'shee mesto v
nashej povsemestnoj zhizni, protokol, na kotorom on osnovan - IP
(Internet Protocol) - priobretaet vse bol'shee znachenie. Dazhe esli vy
ne podklyuchaetes' neposredstvenno k Internet kak k takovomu, IP
protokol i svyazannyj s nim instrumentarij poistine vezdesushchi, delaya
IP standartom "de-fakto" dlya mnogih chastnyh setej.

IP ispol'zuetsya vezde, nachinaya ot prostyh zadach (naprimer,
udalennyj vhod v sistemu (login)) i do bolee slozhnyh (naprimer,
otslezhivanie birzhevyh kotirovok v real'nom vremeni). Vse bol'she i
bol'she kompanij ispol'zuyut World Wide Web ("vsemirnuyu pautinu"),
osnovannuyu na IP, dlya perepiski s klientami, reklamy i drugoj delovoj
aktivnosti.


Menedzher TCP/IP
Menedzher TCP/IP v QNX proishodit iz Berkley BSD 4.3, kotoryj
yavlyaetsya naibolee rasprostranennym stekom TCP/IP v Internet i
ispol'zovan kak osnova dlya mnogih sistem.


Soket API
Biblioteka BSD soketa API byla ochevidnym vyborom dlya QNX 4.
Soket API yavlyaetsya standartnym API dlya programmirovaniya TCP/IP v
srede Unix.  V srede Windows, Winsock API baziruetsya na BSD sokete
API. |to oblegchaet perehod mezhdu nimi.

Imeyutsya vse procedury, kotorye mogut ponadobit'sya prikladnym
programmistam:


accept()

bind()

bindresvport()

connect()

dn_comp()

dn_expand()

endprotoent()

endservent()

gethostbyaddr()

gethostbyname()

getpeername()

getprotobyname()

getprotobynumber()

getprotoent()

getservbyname()

getservent()

getsockname()

getsockopt()

herror()

hstrerror()

htonl()

htons()

h_errlist()

h_errno()

h_nerr()

inet_addr()

inet_aton()

inet_lnaof()

inet_makeaddr()

inet_netof()

inet_network()

inet_ntoa()

ioctl()

listen()

ntohl()

ntohs()

recv()

recvfrom()

res_init()

res_mkquery()

res_query()

res_querydomain()

res_search()

res_send()

select()

send()

sendto()

setprotoent()

setservent()

setsockopt()

shutdown()

socket()

Rasprostranennye utility i demony iz Internet mogut byt' legko
pereneseny ili prosto perekompilirovany v takoj srede. |to oblegchaet
ispol'zovanie imeyushchihsya gotovyh narabotok.


Vozmozhnost' vzaimodejstviya setej
Pri razrabotke Menedzhera TCP/IP v QNX v pervuyu ochered'
prinimalas' vo vnimanie vozmozhnost' vzaimodejstviya setej.  Uchityvalis'
kak trebovaniya RFC, tak i real'nye usloviya.  Menedzher TCP/IP
ohvatyvaet vsyu funkcional'nost', predlagaemuyu RFC 1122.  Takzhe
podderzhivayutsya protokoly ARP, IP, ICMP, UDP i TCP.

NFS
Network File System (NFS) yavlyaetsya prilozheniem TCP/IP,
realizovannym na bol'shinstve DOS i Unix sistem.  NFS pozvolyaet
otobrazhat' udalennye fajlovye sistemy - ili ih chasti - v lokal'noe
prostranstve imen. Fajly na udalennoj sisteme pokazyvayutsya kak chast'
lokal'noj fajlovoj sistemy QNX.





V QNX 4 dlya podderzhki NFS trebuetsya menedzher Socket.  Uchtite,
chto "oblegchennaya" versiya menedzhera, Socklet, mozhet byt'
ispol'zovana, esli net neobhodimosti v NFS.



SMB
Server Message Block (SMB), kotoryj ispol'zuetsya mnogimi razlichnymi
serverami, takimi kak Windows NT, Windows 95, Windows for Workgroups,
LAN Manager i Samba. SMBfsys pozvolyaet klientu QNX prozrachnyj
dostup k udalennym diskam na takih serverah.








Okonnaya sistema Photon microGUI


|ta glava ohvatyvaet sleduyushchie temy:
graficheskoe mikroyadro;
prostranstvo sobytij;
graficheskie drajvery;
masshtabiruemye shrifty;
mnogoyazychnaya podderzhka Unicode;
podderzhka animacii;
podderzhka pechati;
menedzher okon Photon;
biblioteka vidzhetov;
rezyume.

Graficheskoe mikroyadro
Mnogie vstroennye sistemy nuzhdayutsya v pol'zovatel'skom
interfejse.  Dlya slozhnyh prilozhenij ili dlya maksimal'noj prostoty
ispol'zovaniya, estestvennym vyborom yavlyaetsya graficheskaya okonnaya
sistema. Odnako okonnye sistemy nastol'nyh PK trebuyut slishkom mnogo
sistemnyh resursov dlya prakticheskogo primeneniya vo vstroennyh
sistemah, gde pamyat' i stoimost' ogranicheny.
Pri sozdanii okonnoj sistemy Photon microGUI byla primenena
arhitektura mikroyadra, uspeshno voploshchennaya v QNX dlya sozdaniya POSIX
OS dlya vstroennyh sistem.


Dlya uspeshnoj realizacii OS na osnove mikroyadra v pervuyu ochered'
bylo neobhodimo dobit'sya maksimal'noj effektivnosti IPC (tak kak ot
IPC zavisit proizvoditel'nost' vsej OS). Blagodarya voploshchennomu v QNX
mehanizmu IPC s nizkimi izderzhkami, stalo vozmozhnym sozdanie
struktury GUI kak graficheskogo "mikroyadra", okruzhennogo komandoj
vzaimodejstvuyushchih processov, obshchayushchihsya cherez IPC.


Hotya na pervyj vzglyad eto mozhet pokazat'sya pohozhim na postroenie
graficheskoj sistemy po klassicheskoj sheme klient/server, ispol'zuemoj
v X Window System, arhitektura Photon otlichaetsya za schet ogranicheniya
funkcional'nosti, realizuemoj vnutri samogo graficheskogo mikroyadra
(ili servera), i raspredeleniya bol'shej chasti funkcij GUI mezhdu
vzaimodejstvuyushchimi processami.


Mikroyadro Photon vypolnyaetsya kak malen'kij process (razmer koda
45K), realizuya tol'ko neskol'ko fundamental'nyh primitivov, kotorye
vneshnie opcional'nye processy ispol'zuyut dlya postroeniya bolee
vysokogo urovnya funkcional'nosti okonnoj sistemy.  Po ironii, dlya
samogo mikroyadra Photon "okna" ne sushchestvuyut.  Mikroyadro Photon ne
mozhet takzhe "risovat'" chto-libo ili upravlyat' mysh'yu libo klaviaturoj.


Dlya upravleniya sredoj GUI, Photon sozdaet 3-mernoe "prostranstvo
sobytij" i ogranichivaetsya tol'ko operirovaniem regionami i
vypolneniem otsecheniya i napravleniya razlichnyh sobytij po mere ih
prohozhdeniya skvoz' regiony v etom prostranstve sobytij.


|ta abstrakciya napominaet koncepciyu mikroyadra OS, kotoroe ne
podderzhivaet funkcii vvoda/vyvoda dlya ustrojstv ili fajlovoj
sistemy, a polagaetsya na vneshnie processy, predostavlyayushchie eti
uslugi vysokogo urovnya. |to obespechivaet masshtabiruemost' OS i GUI,
postroennyh na osnove mikroyadra, po razmeru i funkcional'nosti .
V osnove "abstrakcii" mikroyadra Photon lezhit voobrazhaemoe
graficheskoe prostranstvo sobytij, v kotoroe drugie processy mogut
pomeshchat' regiony.  Ispol'zuya QNX IPC dlya svyazi s mikroyadrom
Photon, eti processy upravlyayut svoimi regionami dlya predostavleniya
graficheskih servisnyh funkcij vysokogo urovnya ili dlya vypolneniya funkcij
pol'zovatel'skih prilozhenij. Dlya sistem s ogranichennymi resursami Photon
mozhet masshtabirovat'sya "vniz" za schet udaleniya processov,
predostavlyayushchih servisnye funkcii, a za schet dobavleniya
processov, predostavlyayushchih servisnye funkcii, Photon mozhet
masshtabirovat'sya "vverh" do polnofunkcional'noj nastol'noj sistemy.



Prostranstvo sobytij Photon
"Prostranstvo sobytij" mozhno predstavit' kak pustoe trehmernoe
prostranstvo s "kornevym regionom" na zadnem plane. Pol'zovateli
kak budto "smotryat vnutr'" etogo prostranstva sobytij. Prilozheniya
pomeshchayut regiony v trehmernoe prostranstvo mezhdu kornevym regionom i
pol'zovatelem; oni ispol'zuyut eti regiony dlya generacii i priema
razlichnyh tipov sobytij v etom prostranstve.

Processy, kotorye vypolnyayushchie obsluzhivanie drajverov ustrojstv,
pomeshchayut regiony na perednij plan prostranstva sobytij. V dopolnenie
k upravleniyu prostranstvom sobytij i kornevym regionom, mikroyadro
Photon podderzhivaet ekrannyj ukazatel' (kursor), proeciruemyj
kak sobytiya risovaniya po napravleniyu k pol'zovatelyu.





Photon ispol'zuet posledovatel'nost' regionov, nachinaya ot
kornevogo regiona na zadnem plane prostranstva sobytij do
graficheskogo regiona speredi. Sobytiya risovaniya dvigayutsya ot regionov
prilozhenij k graficheskomu regionu.  Sobytiya vvoda voznikayut v regione
kursora/klaviatury i dvigayutsya po napravleniyu k kornevomu regionu.



Dvigayushchiesya v prostranstve sobytij sobytiya mozhno predstavit'
sebe kak "fotony" (chto i dalo nazvanie okonnoj sisteme). Sami
sobytiya sostoyat iz nabora pryamougol'nyh oblastej i prikreplennyh k
nim dannyh.  Po mere dvizheniya sobytij v prostranstve sobytij ih
pryamougol'niki peresekayut regiony, prinadlezhashchie razlichnym processam
(prilozheniyam).
Pro sobytiya, kotorye dvigayutsya ot kornevogo regiona, govoryat,
chto oni peremeshchayutsya naruzhu (po napravleniyu k pol'zovatelyu), v to
vremya kak pro sobytiya ot pol'zovatelya govoryat, chto oni dvigayutsya
vnutr', po napravleniyu k kornevomu regionu.
Vzaimodejstvie mezhdu sobytiyami i regionami lezhit v osnove vvoda
i vyvoda v Photon.  Sobytiya myshi, klaviatury i svetovogo pera
dvigayutsya ot pol'zovatelya k kornevomu regionu, s "prikreplennym" k
nim polozheniem kursora.  Sobytiya risovaniya voznikayut v regionah i
dvigayutsya po napravleniyu k regionu ustrojstva i pol'zovatelyu.

Regiony
Kazhdomu regionu sootvetstvuet pryamougol'naya oblast',
opredelyayushchaya ego polozhenie v 3-mernom prostranstve sobytij. Region
takzhe imeet atributy, opredelyayushchie, kak on vzaimodejstvuet s
razlichnymi klassami sobytij pri peresechenii imi regiona.
Vzaimodejstvie regiona s sobytiyami opredelyaetsya dvumya bitovymi
maskami:


maska chuvstvitel'nosti;
maska neprozrachnosti.
Maska chuvstvitel'nosti opredelyaet, dolzhen li process-vladelec
regiona opoveshchat'sya o peresechenii regiona tem ili inym sobytiem.
Kazhdyj bit maski chuvstvitel'nosti opredelyaet, chuvstvitelen li region
k opredelennomu tipu sobytij.  Kogda sobytie peresekaet region, dlya
kotorogo ustanovlen bit (raven 1), kopiya etogo sobytiya pomeshchaetsya v
ochered' processa-vladel'ca regiona, izveshchaya prilozhenie o prohozhdenii
sobytiya cherez region. Takoe izveshchenie nikak ne izmenyaet samo sobytie.
Maska neprozrachnosti opredelyaet prozrachnost' regiona dlya teh ili
inyh sobytij.  Kazhdyj bit etoj maski opredelyaet, yavlyaetsya li region
prozrachnym dlya opredelennogo tipa sobytiya. Pri prohozhdenii sobytiya
skvoz' "neprozrachnyj" region, ono modificiruetsya.
|ti dve bitovye maski mogut byt' sovmestno ispol'zovany dlya
dostizheniya razlichnyh rezul'tatov. Vozmozhny sleduyushchie chetyre sochetaniya
dlya regiona:

Sochetanie bitovyh masok:
        
Opisanie:
Nechuvstvitel'nyj, prozrachnyj.
        
Pri prohozhdenii sobytiya cherez region, ono ne modificiruetsya, i
vladelec regiona ne izveshchaetsya.  Process-vladelec regiona prosto ne
interesuetsya sobytiem.
Nechuvstvitel'nyj, neprozrachnyj.
        
Pri prohozhdenii sobytiya cherez region, ono otsekaetsya; vladelec
regiona ne izveshchaetsya.  Bol'shinstvo prilozhenij ispol'zuyut takuyu
kombinaciyu atributov dlya otsecheniya sobytij risovaniya, chtoby izbezhat'
pererisovki okna sobytiyami risovaniya, ishodyashchimi ot lezhashchih pod nim
okon.
CHuvstvitel'nyj, prozrachnyj.
        
Kopiya sobytiya napravlyaetsya vladel'cu regiona; sobytie prodolzhit
dvizhenie v prostranstve sobytij, ne izmenyayas'.  Process, zhelayushchij
registrirovat' prohozhdenie vseh sobytij, mozhet ispol'zovat' takuyu
kombinaciyu.
CHuvstvitel'nyj, neprozrachnyj.
        
Kopiya sobytiya napravlyaetsya vladel'cu regiona; sobytie otsekaetsya
regionom. Ustanoviv takuyu kombinaciyu masok, sobytie mozhet igrat'
rol' fil'tra ili preobrazovatelya. Prilozhenie mozhet obrabotat' lyuboe
poluchennoe sobytie, regenerirovat' ego i pri neobhodimosti
preobrazovat' ego kakim-libo obrazom pri etom, vozmozhno, izmeniv
napravlenie dvizheniya ili koordinaty. Naprimer, region mozhet pogloshchat'
sobytiya svetovogo pera, vypolnyat' raspoznavanie pocherka, a zatem
generirovat' ekvivalentnye sobytiya nazhatiya klavish.


Sobytiya
Podobno regionam, sobytiya mogut otnosit'sya k razlichnym klassam i
imet' razlichnye atributy, kak, naprimer:
region proishozhdeniya;
tip;
napravlenie;
prikreplennyj spisok pryamougol'nikov;
specificheskie dlya dannogo sobytiya dannye.
V otlichie ot bol'shinstva okonnyh sistem, Photon
klassificiruet ne tol'ko vvod (pero, mysh', klaviatura t.d.),
no i vyvod (zaprosy risovaniya) kak sobytiya.  Sobytiya mogut
generirovat'sya kak regionami, kotorye processy pomestili v
prostranstvo sobytij, tak i samim mikroyadrom Photon.  Opredeleny
sleduyushchie tipy sobytij:


nazhatiya klavish;
nazhatiya pera i knopok myshi;
peremeshcheniya pera i myshi;
peresechenie granic regiona;
sobytiya ekspozicii i perekrytiya;
sobytiya risovaniya;
sobytiya peretaskivaniya (drag).
Prilozheniya mogut libo zhdat' nastupleniya sobytij, i pri etom
blokirovat'sya, libo poluchat' asinhronnye izveshcheniya o prihode sobytiya.
Spisok pryamougol'nikov, prikreplennyj k sobytiyu, mozhet
opredelyat' odnu ili bolee pryamougol'nyh oblastej, libo "ishodnuyu
tochku" - edinstvennyj pryamougol'nik, u kotorogo koordinaty verhnego
levogo i nizhnego pravogo uglov sovpadayut.



Pri peresechenii sobytiem neprozrachnogo regiona, pryamougol'nik
regiona "vyrezaetsya" iz spiska pryamougol'nikov sobytiya tak, chto
spisok opisyvaet teper' tol'ko vidimuyu chast' sobytiya.

Luchshe vsego illyustriruet takoe otsechenie to, kak izmenyaetsya
spisok pryamougol'nikov sobytiya risovaniya po mere ego prohozhdeniya
skvoz' razlichnye regiony.  Kogda sobytie risovaniya generiruetsya,
spisok pryamougol'nikov soderzhit edinstvennyj pryamougol'nik,
opisyvayushchij porodivshij sobytie region.
Esli sobytie prohodit cherez region, kotoryj otsekaet, naprimer,
verhnij levyj ugol sobytiya risovaniya, to spisok pryamougol'nikov
modificiruetsya i budet soderzhat' uzhe dva pryamougol'nika, kotorye
opredelyayut oblast', podlezhashchuyu otrisovke.  |ti rezul'tiruyushchie
pryamougol'niki nazyvayutsya "plitki" (tiles).
Podobnym obrazom, kazhdyj raz pri peresechenii sobytiem risovaniya
neprozrachnogo regiona, spisok pryamougol'nikov budet modificirovat'sya
takim obrazom, chtoby opisyvat' oblast', ostavshuyusya vidimoj posle
"vyrezaniya" neprozrachnogo regiona.  Kogda, nakonec, sobytie risovaniya
dostignet graficheskogo drajvera, to spisok pryamougol'nikov budet
tochno opisyvat' tol'ko ego vidimuyu chast'.




Neprozrachnye dlya sobytiya risovaniya regiony vyrezayutsya, v
rezul'tate chego poluchaetsya oblast', sostoyashchaya iz pryamougol'nyh
"plitok".



V tom sluchae, esli sobytie risovaniya celikom otsekaetsya pri
peresechenii s regionom, ono prekrashchaet sushchestvovanie.  |tot mehanizm
"neprozrachnyh" okon, izmenyayushchih spisok pryamougol'nikov sobytiya
risovaniya, obespechivaet pravil'noe otsechenie sobytij risovaniya po
mere ih prodvizheniya ot ishodnogo regiona (i svyazannogo s nim
processa) k pol'zovatelyu.


Graficheskie drajvery
Graficheskie drajvery realizovany kak processy, kotorye pomeshchayut
region na perednem plane prostranstva sobytij. Region graficheskogo
drajvera chuvstvitelen k sobytiyam risovaniya, ishodyashchim iz
prostranstva sobytij. Graficheskij drajver poluchaet sobytiya risovaniya,
kogda oni peresekayut ego region. Mozhno predstavit' sebe, chto region
pokryt "fosforom", kotoryj svetitsya pri popadanii "fotonov".



Tak kak API risovaniya Photon nakaplivaet zaprosy risovaniya v
pakety, posylaemye kak odno sobytie risovaniya, to kazhdoe sobytie
risovaniya, poluchaemoe drajverom, soderzhit spisok graficheskih
primitivov, podlezhashchih otrisovke.  K momentu peresecheniya sobytiem
risovaniya regiona drajvera, spisok pryamougol'nikov budet soderzhat'
takzhe "spisok otsechenij", opisyvayushchij, kakie imenno chasti spiska
risovaniya dolzhny otobrazhat'sya na displee. Rabota drajvera zaklyuchaetsya
v tom, chtoby preobrazovat' rezul'tiruyushchij spisok v vizual'noe
otobrazhenie na kontroliruemom graficheskom oborudovanii.
Odno iz preimushchestv ispol'zovaniya spiska pryamougol'nikov vnutri
sobytiya sostoit v tom, chto kazhdoe peredavaemoe drajveru sobytie
predstavlyaet soboj fakticheski "paket" zaprosov.  Po mere
sovershenstvovaniya graficheskogo oborudovaniya, vse bol'she i bol'she
takoj "paketnoj" raboty mozhet peredavat'sya neposredstvenno
oborudovaniyu.  Mnogie videoadaptery uzhe podderzhivayut apparatno odnu
oblast' otsecheniya, a nekotorye podderzhivayut i neskol'ko oblastej.
Hotya ispol'zovanie mehanizma QNX IPC dlya peredachi zaprosov
risovaniya ot prilozhenij k graficheskomu drajveru i mozhet pokazat'sya
nepriemlemoj izbytochnost'yu, testy proizvoditel'nosti pokazyvayut, chto
proizvoditel'nost' v dannom variante ne huzhe, chem v sluchae, kogda
prilozheniya vypolnyayut pryamye vyzovy drajvera. Odnoj iz prichin yavlyaetsya
to, chto pri ispol'zovanii sobytij mnogochislennye zaprosy risovaniya
gruppiruyutsya, chto umen'shaet kolichestvo posylaemyh soobshchenij po
sravneniyu s kolichestvom pryamyh vyzovov drajvera.

Neskol'ko graficheskih drajverov
Iz togo, chto graficheskij drajver prosto pomeshchaet region v
prostranstvo sobytij Photon, estestvenno sleduet, chto odnovremenno
mogut byt' zapushcheny neskol'ko graficheskih drajverov dlya neskol'kih
videoadapterov, pri etom kazhdyj drajver budet imet' svoj,
chuvstvitel'nyj k sobytiyam risovaniya, region.


|ti regiony mogut byt' raspolozheny ryadom, libo perekryvat' drug
druga proizvol'nym obrazom.  Tak kak Photon nasleduet ot QNX setevuyu
prozrachnost', to prilozheniya ili drajvery Photon mogut vypolnyat'sya na
lyubom uzle seti, pozvolyaya, takim obrazom, dopolnitel'nym graficheskim
drajveram rasshiryat' graficheskoe prostranstvo Photon za schet
fizicheskih displeev drugih komp'yuterov v seti. Za schet perekrytiya
regionov graficheskih drajverov, sobytiya risovaniya mogut dublirovat'sya
na neskol'kih ekranah.
Mnogie interesnye prilozheniya stali vozmozhny blagodarya etim
svojstvam Photon.  Naprimer, na zavode operator s portativnym
komp'yuterom, imeyushchim besprovodnoe podklyuchenie k seti, mozhet podojti k
rabochej stancii i "peretashchit'" panel' upravleniya s ee monitora na
ekran portativnogo komp'yutera, a zatem perejti v ceh i osushchestvlyat'
upravlenie.
V drugih prilozheniyah vstroennaya sistema bez pol'zovatel'skogo
interfejsa mozhet proecirovat' displej na lyuboj iz uzlov seti.  Krome
togo, stanovitsya vozmozhnym kollektivnyj rezhim raboty - neskol'ko
chelovek, nahodyas' za svoimi komp'yuterami, mogut odnovremenno videt'
odni i te zhe okna i rabotat' s odnim i tem zhe prilozheniem.
S tochki zreniya prilozheniya, eto vyglyadit kak odno edinoe
graficheskoe prostranstvo.  S tochki zreniya pol'zovatelya, eto vyglyadit
kak gruppa soedinennyh komp'yuterov, gde mozhno peretaskivat' okna s
odnogo fizicheskogo ekrana na drugoj.


Cvetovaya model'
Dlya predstavleniya cvetov ispol'zuetsya 24-bitnaya RGB model' (po 8
bit dlya krasnogo, zelenogo i sinego), chto obespechivaet 16,777,216
cvetov.  V zavisimosti ot ispol'zuemogo tipa oborudovaniya, drajver
libo neposredstvenno otobrazhaet 24-bitnyj cvet, libo ispol'zuet
razlichnye varianty smeshivaniya cvetov, chtoby otobrazit' trebuemyj cvet
na oborudovanii, podderzhivayushchem men'shee chislo cvetov.

Tak kak graficheskie drajvery ispol'zuyut apparatno-nezavisimoe
predstavlenie cvetov, to prilozheniya mogut rabotat' bez izmeneniya na
razlichnom oborudovanii, nezavisimo ot togo, kakuyu cvetovuyu model' ono
podderzhivaet.  |to pozvolyaet "peretaskivat'" prilozheniya s odnogo
monitora na drugoj, ne zadumyvayas' o tom, kakaya cvetovaya model'
apparatno realizovana v kazhdom konkretnom sluchae.


Masshtabiruemye shrifty
V dopolnenie k podderzhke rastrovyh shriftov, Photon takzhe
predlagaet masshtabiruemye shrifty. |ti shrifty mogut masshtabirovat'sya
prakticheski s lyubym razmerom tochki i ispol'zovat' tehnologiyu
sglazhivaniya (16 ottenkov) dlya chetkogo i yasnogo otobrazheniya na ekrane
s lyubym razresheniem.
Masshtabiruemye shrifty v Photon podderzhivayutsya bystrodejstvuyushchim
serverom shriftov, kotoryj zagruzhaet opisaniya shriftov, hranyashchiesya v
szhatom vide v fajlah *.pfr (Portable Font Resource, resursy
perenosimyh shriftov), i zatem privodit vid simvolov v sootvetstvie s
lyubym razmerom tochki i razresheniem. Stoit otmetit', chto format PFR
obespechivaet bolee chem v dva raza luchshee szhatie po sravneniyu s
PostScript shriftami.


Nabory shriftov

Osnovnoj latinskij nabor
Osnovnoj latinskij (Core Latin) nabor shriftov
Photon (latin1.pfr), kotoryj ohvatyvaet dva nabora
simvolov standarta Unicode, Basic Latin (U+0000 - U+007F)
i Latin-1 Supplement (U+0080 - U+00FF), vklyuchaet sleduyushchie
masshtabiruemye shrifty:
Dutch;
Dutch Bold;
Dutch Italic;
Dutch Bold Italic;
Swiss;
Swiss Bold;
Swiss Italic;
Swiss Bold Italic;
Courier;
Courier Bold;
Courier Italic;
Courier Bold Italic.
Rasshirennyj latinskij nabor
Rasshirennyj latinskij (Extended Latin) nabor
(latinx.pfr) ohvatyvaet nabory simvolov Unicode Latin
Extended-A (U+0100 - U+017F) i Latin Extended-B (U+0180 -
U+0217) i vklyuchaet sleduyushchie shrifty:
Dutch;
Dutch Bold;
Dutch Italic (generiruetsya algoritmicheski);
Dutch Bold Italic (generiruetsya algoritmicheski);
Swiss;
Swiss Bold;
Swiss Italic (generiruetsya algoritmicheski);
Swiss Bold Italic (generiruetsya algoritmicheski).
Podderzhivaemye yazyki
Imeya v svoem rasporyazhenii Osnovnoj latinskij nabor (latin1.pfr),
razrabotchik mozhet podderzhivat' mnozhestvo yazykov, vklyuchaya:

Datskij;

Gollandskij;

Anglijskij;

Finskij;

Flamandskij;

Francuzskij;

Nemeckij;

Gavajskij;

Islandskij;

Indonezijskij;

Irlandskij;

Ital'yanskij;

Norvezhskij;

Portugal'skij;

Ispanskij;

Suahili;

SHvedskij.

Rasshirennyj nabor (latinx.pfr) pozvolyaet dopolnitel'no podderzhivat':

Afrikanskij;

Baskskij;

Katalonskij;

Horvatskij;

CHeshskij;

|speranto;

|stonskij;

Grenlandskij;

Vengerskij;

Latyshskij;

Litovskij;

Mal'tijskij;

Pol'skij;

Rumynskij;

Slovackij;

Tureckij;

Vallijskij.

Dopolnitel'nye yazykovye pakety
Dlya Photon predlagayutsya neskol'ko dopolnitel'nyh
paketov dlya podderzhki nacional'nyh yazykov:

YAponskij;
Kitajskij;
Korejskij;
Kirillica.



Mnogoyazychnaya podderzhka Unicode
Photon razrabotan s uchetom podderzhki nacional'nyh simvolov.
Sleduya standartu Unicode (ISO/IEC 10646), Photon predostavlyaet
razrabotchikam vozmozhnost' sozdavat' prilozheniya, podderzhivayushchie
osnovnye mirovye yazyki.

Unicode osnovyvaetsya na nabore simvolov ASCII, no ispol'zuet
16-bitnuyu kodirovku dlya polnoj podderzhki mnogoyazychnogo teksta. Net
nikakoj neobhodimosti pribegat' k escape-posledovatel'nostyam ili
upravlyayushchim kodam dlya zadaniya lyubogo simvola lyubogo yazyka. Zamet'te,
chto kodirovka Unicode obrabatyvaet vse simvoly - alfavitnye,
ideogrammy, special'nye simvoly - absolyutno odinakovym obrazom.

UTF-8 kodirovka
Izvestnaya ran'she kak UTF-2, UTF-8 (ot "8-bitnaya forma")
kodirovka opredelyaet ispol'zovanie simvolov Unicode v 8-bitnoj srede
UNIX.

Vot nekotorye osnovnye harakteristiki UTF-8:
Unicode-simvoly ot U+0000 do U+007E (nabor ASCII) otobrazhayutsya
v UTF-8-bajty ot 00 do 7E (ASCII-znacheniya);
ASCII-znacheniya ne vstrechayutsya inym obrazom v UTF-8,
obespechivaya polnuyu sovmestimost' s fajlovymi sistemami, kotorye
analiziruyut ASCII-bajty;
UTF-8 uproshchaet preobrazovanie v Unicode-tekst i iz nego;
Pervyj bajt ukazyvaet kolichestvo bajt v mnogobajtnoj
posledovatel'nosti, obespechivaya effektivnyj razbor;
Mozhno legko najti nachalo simvola iz lyubogo mesta v potoke
bajt, tak kak dlya etogo neobhodimo perebrat' ne bolee chetyreh bajt, a
nachal'nyj bajt legko opredelit'. Naprimer:
isInitialByte = ((byte & 0xC0) != 0x80);



UTF-8 dostatochno kompakten, imeya v vidu kolichestvo
bajt, ispol'zuemyh dlya kodirovki.
Sistemnaya biblioteka vklyuchaet ryad funkcij
preobrazovaniya:

Funkciya:
Opisanie:
mblen()
Dlina mnogobajtnoj stroki v simvolah
mbtowc()
Preobrazovat' mnogobajtnyj simvol v dvuhbajtnyj simvol
mbstowcs()
Preobrazovat' mnogobajtnuyu stroku v dvuhbajtnuyu stroku
wctomb()
Preobrazovat' dvuhbajtnyj simvol v ego mnogobajtnoe predstavlenie
wcstombs()
Preobrazovat' stroku dvuhbajtnyh simvolov v mnogobajtnuyu stroku

V dopolnenie k perechislennym vyshe funkciyam, razrabotchiki mogut takzhe
vospol'zovat'sya sobstvennoj bibliotekoj Photon, funkciyami
PxTranslate, kotorye vypolnyat razlichnye preobrazovaniya
naborov simvolov v/iz UTF-8.


Podderzhka animacii
Photon obespechivaet nemercayushchuyu animaciyu cherez special'nyj
vidzhet-kontejner s "dvojnym buferom" (PtDBContainer), kotoryj
sozdaet special'nyj kontekst v pamyati dlya otrisovki izobrazhenij.
Vidzhet PtDBContainer ispol'zuet blok razdelyaemoj pamyati,
dostatochnyj dlya hraneniya izobrazheniya sootvetstvuyushchego razmera.



Podderzhka pechati
Photon predusmatrivaet vstroennuyu podderzhku pechati s vyvodom na
razlichnye ustrojstva, vklyuchaya:
fajly bitovyh kart;
PostScript;
Hewlett-Packard PCL;
Epson ESC/P2;
Canon;
Lexmark.

Photon takzhe soderzhit vidzhet/dialog vybora printera, oblegchaya
pechat' iz prilozhenij.



Menedzher okon Photon
Dobavlenie Menedzhera okon prevrashchaet Photon v
polnofunkcional'nyj nastol'nyj graficheskij interfejs (GUI). Menedzher
okon ne yavlyaetsya obyazatel'nym i mozhet otsutstvovat' v bol'shinstve
vstroennyh sistem.  Menedzher okon pozvolyaet pol'zovatelyam
manipulirovat' oknami prilozhenij, izmenyaya ih razmer, peremeshchaya i
minimiziruya.

Menedzher okon ispol'zuet koncepciyu fil'tracii sobytij.  On
pomeshchaet dopolnitel'nye regiony za regionami prilozhenij, na kotoryh
"narisovany" elementy upravleniya oknami.  Tak kak vid i povedenie
interfejsa opredelyayutsya zamenyaemym Menedzherom okon, to mozhno
realizovat' razlichnye vidy pol'zovatel'skih interfejsov.


Biblioteka vidzhetov
Photon predlagaet biblioteku komponentov, nazyvaemyh vidzhetami,-
ob®ektov, sposobnyh, v osnovnom, avtomaticheski upravlyat' svoim
povedeniem bez neposredstvennogo programmirovaniya.  V rezul'tate,
zavershennoe prilozhenie mozhet byt' bystro sobrano iz vidzhetov, s
posleduyushchej privyazkoj C-koda k sootvetstvuyushchim callback-funkciyam
vidzhetov. Photon Application Builder (PhAB), kotoryj yavlyaetsya chast'yu
sistemy razrabotki Photon, podderzhivaet shirokuyu palitru vidzhetov v
vizual'noj srede razrabotki.


Photon predlagaet shirokij spektr vidzhetov:
 bazovye vidzhety (naprimer, knopka);
 vidzhety-kontejnery (naprimer, okno);
 slozhnye vidzhety (naprimer, HTML-vidzhet).
Bazovye vidzhety

Vidzhet YArlyk (PtLabel)




Dannyj vidzhet ispol'zuetsya v osnovnom dlya otobrazheniya tekstovoj
informacii.  Vidzhet PtLabel yavlyaetsya nadklassovym dlya vseh
tekstovyh vidzhetov, obespechivaya mnogie nastraivaemye atributy
(naprimer, shrift, vsplyvayushchie ballony, cveta, bordyur, vyravnivanie,
polya i t.d.), kotorye nasleduyutsya vsemi podklassami.

Vidzhet Knopka (PtButton)




Knopki yavlyayutsya neot®emlemym komponentom lyuboj okonnoj obolochki.
Obychno oni imeyut vypuklyj vid, kotoryj pri nazhatii smenyaetsya na
utoplennyj, vizual'no otrazhaya vybor knopki.  V dopolnenie k
vizual'nomu otrazheniyu sostoyaniya, pri vybore knopki avtomaticheski
vyzyvaetsya opredelennaya prilozheniem callback-funkciya.

Vidzhety Tekstovyj vvod (PtText, PtMultiText)




Photon predlagaet dva vidzheta tekstovogo vvoda:
 prostoj odnostrochnyj (PtText), obychno ispol'zuemyj v
formah;
 mnogostrochnyj, s moshchnymi vozmozhnostyami redaktirovaniya vidzhet
(PtMultiText), obespechivayushchij vse vozmozhnosti redaktirovaniya,
avtomaticheskoj prokrutki, podderzhku mnozhestva shriftov.
Vidzhety Knopka s fiksaciej (PtToggleButton, PtOnOffButton)




Knopki s fiksaciej otobrazhayut odno iz dvuh vozmozhnyh sostoyanij -
vklyucheno ili vyklyucheno. Photon predlagaet dva razlichnyh tipa knopok s
fiksaciej s razlichnym vneshnim vidom. Knopki s fiksaciej ispol'zuyutsya
dlya otobrazheniya ili vvoda informacii o sostoyanii kakoj-libo komandy
ili dejstviya.


Graficheskie vidzhety (PtArc, PtPixel, PtRectangle,
PtLine, PtPolygon, PtEllipse, PtBezier,
PtGrid)




Photon ne ispytyvaet nedostatka v graficheskih vidzhetah.
Sushchestvuyut vidzhety dlya vsego, nachinaya ot prostyh linij i
pryamougol'nikov i do slozhnyh mnogosegmentnyh krivyh Bez'e.
Graficheskie vidzhety imeyut atributy dlya cvetov, zapolneniya, tolshchiny
linij i mnogo drugogo.

Vidzhet Polosa prokrutki (PtScrollbar)




Dannyj vidzhet ispol'zuetsya dlya prokrutki izobrazheniya v vidimoj
oblasti.  Polosa prokrutki takzhe ispol'zuetsya v sostave drugih
vidzhetov (naprimer, PtList, PtScrollArea) dlya obespecheniya
prokrutki.

Vidzhet Razdelitel' (PtSeparator)




Dannyj vidzhet ispol'zuetsya dlya razdeleniya dvuh ili bolee
oblastej, pridavaya luchshij vneshnij vid.  Razdelitel' mozhet byt'
nastroen v sootvetstvii s razlichnymi stilyami i vidami.

Vidzhet Dvizhok (PtSlider)




Dvizhok otlichaetsya ot polosy prokrutki tem, chto polosa prokrutki
opredelyaet interval, v to vremya kak dvizhok zadaet edinstvennoe
znachenie. Vidzhet Dvizhok predusmatrivaet bol'shoj spisok nastraivaemyh
atributov.

Vidzhet Tajmer (PtTimer)
Vidzhet Tajmer sushchestvenno uproshchaet ispol'zovanie tajmera.  |tot
vidzhet ne otobrazhaetsya vizual'no - on prosto opredelyaet
callback-funkciyu, vyzyvaemuyu vsyakij raz pri srabatyvanii tajmera.
Prilozhenie mozhet ustanavlivat' znachenie tajmera i, po vyboru,
interval povtoreniya.

Vidzhety Graficheskoe izobrazhenie (PtBitmap, PtLabel,
PtButton)




Photon podderzhivaet vse osnovnye formaty graficheskih fajlov, chto
pozvolyaet importirovat' izobrazheniya i pokazyvat' ih vnutri vidzhetov.
Mnogie vidzhety Photon neposredstvenno podderzhivayut otobrazhenie
grafiki - naibolee ispol'zuemymi yavlyayutsya PtButton, dlya
sozdaniya panelej knopok, i PtLabel, dlya pokaza izobrazhenij.

Vidzhet Indikator hoda processa (RtProgress)




Esli prilozheniyu neobhodimo vypolnit' kakuyu-libo dlitel'nuyu
operaciyu (naprimer, zagruzit' fajl), ono mozhet ispol'zovat' indikator
hoda processa, chtoby pokazat' pol'zovatelyu, chto proishodit i, chto eshche
bolee vazhno, skol'ko eshche vremeni zajmet etot process.  Indikator hoda
processa mozhet byt' gorizontal'nym ili vertikal'nym i imeet mnogo
nastraivaemyh atributov.

Vidzhet Soobshchenie (PtMessage)




Vsplyvayushchie soobshcheniya i preduprezhdeniya tipichny dlya okonnoj
sredy. Photon predusmatrivaet ochen' udobnyj vidzhet dialoga, kotoryj
pokazyvaet soobshchenie, i do 3 knopok dlya otveta pol'zovatelya.  Imeetsya
takzhe poleznaya funkciya vyzova modal'nogo dialoga
(PtAskQuestion()), osnovannaya na dannom vidzhete.

CHislovye vidzhety (PtNumericInteger, PtNumericFloat)




PtNumericInteger pozvolyaet pol'zovatelyu zadat'
celochislennoe znachenie v predelah mezhdu ustanovlennymi minimal'noj i
maksimal'noj velichinami.  PtNumericFloat pozvolyaet vvesti
chislo s plavayushchej tochkoj.
Vidzhet PtUpDown (strelki vverh/vniz) pozvolyaet
pol'zovatelyu uvelichivat' ili umen'shat' chislo na zadannuyu velichinu.


Vidzhety-kontejnery

Vidzhety Okno i Piktogramma (PtWindow, PtIcon)




Okna yavlyayutsya osnovnymi kontejnerami dlya prilozhenij. Osnovnye
komponenty pol'zovatel'skogo interfejsa (linejki menyu, linejki
instrumentov i t.d.) poyavlyayutsya s vidzhetom Okno. Vidzhet avtomaticheski
vypolnyaet vse neobhodimye vzaimodejstviya s Menedzherom okon Photon
(PWM) - vam trebuetsya tol'ko zadat' trebuemuyu funkcional'nost'.
Vidzhety Piktogrammy tesno svyazany s oknami i pokazyvayutsya v
papkah Photon Desktop Manager i na paneli zadach PWM.

Vidzhet Panel' (PtPane)




Vidzhety Panel' yavlyayutsya prostymi vidzhetami-kontejnerami, kotorye
ispol'zuyutsya dlya razmeshcheniya drugih vidzhetov.  Hotya on i yavlyaetsya
roditel'skim vidzhetom, panel' nikakim obrazom ne upravlyaet dochernimi
vidzhetami.  Paneli ochen' udobny dlya postroeniya form, obychno
vstrechayushchihsya v oknah dialoga.

Vidzhet Gruppa (PtGroup)




Vidzhet Gruppa - eto ochen' moshchnyj vidzhet, kotoryj upravlyaet
geometriej vseh svoih dochernih vidzhetov. On mozhet vyravnivat' vidzhety
po gorizontali, po vertikali ili v vide matricy.  Gruppa mozhet byt'
privyazana k storone lyubogo drugogo kontejnera (naprimer, okna) takim
obrazom, chtoby gruppa avtomaticheski izmenyala razmer pri izmenenii
razmera okna.  Vidzhet Gruppa takzhe predusmatrivaet atributy, kotorye
pozvolyayut zadat' neobhodimost' rastyagivaniya dochernih vidzhetov pri
uvelichenii razmerov gruppy.

Vidzhet Oblast' prokrutki (PtScrollArea)




Oblast' prokrutki obespechivaet "okno" prosmotra soderzhimogo
kontejnera potencial'no bol'shego razmera.  Vy mozhete pomestit' lyuboe
kolichestvo vidzhetov vnutr' oblasti prokrutki, i ona avtomaticheski
sozdast polosy prokrutki v sluchae, esli vidzhety vyhodyat za granicy
vidimoj oblasti.  Oblasti prokrutki mogut byt' ispol'zovany dlya
sozdaniya okna prosmotra tekstovyh fajlov, tekstovyh redaktorov,
prosmotra spiskov i tak dalee.
Dlya bystroj prokrutki dochernih vidzhetov oblast' prokrutki
ispol'zuet apparatnyj blitter (pri uslovii, chto on podderzhivaetsya
graficheskim drajverom).

Vidzhet Fon (PtBkgd)




Dannyj vidzhet pozvolyaet sozdavat' lyuboj fon, nachinaya ot prostogo
perehoda cvetov do simmetrichno raspolozhennyh tekstur. Prakticheski
lyuboe trebovanie k fonu mozhet byt' udovletvoreno etim vidzhetom.

Slozhnye vidzhety

Vidzhety Menyu (PtMenu, PtMenuBar, PtMenuButton)




Photon predusmatrivaet vse neobhodimoe dlya organizacii menyu.
Vidzhet PtMenuBar uproshchaet sozdanie standartnoj linejki menyu.
Vidzhet PtMenu obrabatyvaet otobrazhenie vsplyvayushchego menyu,
nazhatie-peremeshchenie-otpuskanie (myshi), ukazanie i nazhatie, vvod s
klaviatury i vybor punktov menyu.  Vidzhet PtMenuButton
ispol'zuetsya dlya sozdaniya otdel'nyh punktov menyu.

Vidzhet Spisok (PtList)




Dannyj vidzhet upravlyaet spiskom elementov. On predusmatrivaet
mnogo razlichnyh rezhimov vybora, vklyuchaya edinichnyj vybor,
mnozhestvennyj vybor i vybor diapazona.  Vidzhet Spisok takzhe
podderzhivaet mnogostolbcovye spiski pri ispol'zovanii vidzheta PtDivider.

Vidzhet Razvorachivaemyj spisok (PtComboBox)




Razvorachivaemyj spisok sovmeshchaet vidzhet PtText (dlya
vvoda teksta) s knopkoj dlya otobrazheniya vidzheta PtList. Pri
vybore pol'zovatelem elementa spiska, vidzhet Tekst avtomaticheski
obnovlyaetsya v sootvetstvii s tekushchim vyborom.  Razvorachivaemyj spisok
ochen' polezen v dlya otobrazheniya spiska v ogranichennom prostranstve.
Dialogi i kontejnery zanimayut znachitel'no men'she mesta na ekrane, chto
osobenno vazhno dlya vstroennyh prilozhenij.

Vidzhet Derevo (PtTree)




Vidzhet Derevo napominaet vidzhet Spisok - oni imeyut obshchih
predshestvennikov. Osnovnoe otlichie sostoit v tom, chto vidzhet Derevo
pokazyvaet elementy v vide ierarhii. |lementy, nazyvaemye vetvyami,
mogut byt' razvernuty ili szhaty; mozhet byt' sozdano lyuboe kolichestvo
vetvej. Dlya kazhdoj vetvi mozhno opredelit' svoe unikal'noe graficheskoe izobrazhenie.
V chislo prilozhenij Photon, ispol'zuyushchih derev'ya, vhodyat:
Fajl-Menedzher (pokaz kataloga), PhAB (ierarhiya vidzhetov), vsin
(spisok processov) i mnogie drugie.

Vidzhety Terminal (PtTty, PtTerminal)




Blagodarya etomu vidzhetu est' vozmozhnost' pomestit' tekstovuyu
konsol' v svoe prilozhenie.  Vidzhet Terminal sozdaet tekstovyj
terminal i upravlyaet im.

Bolee togo - on obespechivaet polnuyu funkcional'nost'
"cut-and-paste" i bystryj vyzov spravki putem vydeleniya teksta vnutri
vidzheta.

Vidzhet Delitel' (PtDivider)




|tot vidzhet osushchestvlyaet upravlenie dochernimi vidzhetami
unikal'nym obrazom.  Esli pomestit' dva ili bolee vidzheta vnutr'
vidzheta PtDivider, to on avtomaticheski sozdaet nebol'shie
razdeliteli mezhdu dochernimi vidzhetami.  Peredvigaya eti razdeliteli,
pol'zovatel' mozhet izmenyat' razmery dochernih vidzhetov.  |to ochen'
udobno, v chastnosti, dlya sozdaniya spiskov so stolbcami izmenyaemoj
shiriny. Fakticheski, esli pomestit' vidzhet PtDivider
vnutr' PtList, eto avtomaticheski prevratit prostoj spisok v
spisok s mnozhestvennymi stolbcami izmenyaemoj shiriny.
Vitzhety Deliteli ne ogranichivayutsya tol'ko etiketkami ili knopkami.
Lyuboj vidzhet mozhet byt' pomeshchen vnutr', chtoby sozdavat' ryadom
derev'ya s izmenyaemymi razmerami, oblasti prokrutki i tak dalee.



Vidzhet Trend (RtTrend)




Sistemy real'nogo vremeni chasto trebuyut otobrazheniya graficheskih
trendov sostoyaniya processa.  Vidzhet RtTrend
podderzhivaet otobrazhenie neskol'kih trendov odnovremenno.

Vidzhet Izmeritel'nyj pribor (RtMeter)




Vidzhet RtMeter imeet vid polukruga s riskami,
otmechayushchimi 1/3, 1/2 i 2/3 dliny dugi. Strelka mozhet peremeshchat'sya s
pomoshch'yu myshi ili klaviatury ili programmno.  Odnokratnoe nazhatie
knopki myshi peremeshchaet strelku v tekushchuyu poziciyu kursora; pri nazhatii
i posleduyushchem peremeshchenii myshi ("drag") strelka sleduet za kursorom.

Dialog vybora shrifta (PtFontSel)




|tot vidzhet chitaet standartnye fajly konfiguracii shriftov i
pokazyvaet spisok dostupnyh shriftov.  On pozvolyaet vybrat' shrift i
stil' (zhirnyj, kursiv t.d.) i takzhe ukazat' neobhodimost'
ispol'zovaniya tehnologii sglazhivaniya (anti-alias).


Vidzhet Vybor fajla (PtFileSel)




Vidzhet PtFileSel pozvolyaet otobrazhat' drevovidnuyu
ierarhiyu fajlov, katalogov ili proizvol'nyh elementov.  S pomoshch'yu
etogo vidzheta pol'zovatel' mozhet prosmatrivat' strukturu fajlovoj
sistemy i vybirat' trebuemyj fajl ili katalog.


Dialog nastrojki pechati (PtPrintSel)




Vidzhet PtPrintSel pozvolyaet pol'zovatelyu vybrat' printer
i proizvesti neobhodimuyu nastrojku parametrov pechati. Pol'zovatel'
mozhet zadat' diapazon stranic dlya vyvoda na pechat' i kolichestvo
kopij.


Vidzhet HTML (PtHtml)




Ispol'zovanie dannogo vidzheta oblegchaet sozdanie sobstvennogo
sredstva prosmotra dokumentacii formata HTML. Vidzhet sam vypolnyaet
formatirovanie standartnogo HTML-fajla i dazhe avtomaticheski zagruzhaet
kartinki. On obrabatyvaet prokrutku, izmenenie razmera, prakticheski
vse trebuemye funkcii.

Sozdanie novyh vidzhetov
Esli standartnyh vidzhetov Photon nedostatochno, to vy mozhete
legko sozdat' svoi sobstvennye novye vidzhety!  V sostav sredy
razrabotki Photon vhodit polnaya dokumentaciya i primery ishodnogo koda
dlya sozdaniya sobstvennyh vidzhetov.  Vy mozhete sozdavat' podklassy
sushchestvuyushchih vidzhetov, chtoby obespechit' nasledovanie ih
funkcional'nosti, ili sozdat' sobstvennoe derevo vidzhetov.



Rezyume
Photon olicetvoryaet novyj podhod k sozdaniyu graficheskogo
pol'zovatel'skogo interfejsa s ispol'zovaniem mikroyadra i "komandy"
vzaimodejstvuyushchih processov, a ne monolitnyj podhod, harakternyj dlya
drugih okonnyh sistem. V rezul'tate Photon demonstriruet unikal'nye
harakteristiki:
Nizkie trebovaniya k ob®emu pamyati pozvolyayut Photon
obespechivat' vysokij uroven' funkcional'nosti okonnoj obolochki v
usloviyah, gde ranee bylo vozmozhno tol'ko ispol'zovanie graficheskoj
biblioteki.
Photon obladaet ochen' gibkoj, narashchivaemoj arhitekturoj,
kotoraya pozvolyaet razrabotchikam rasshiryat' vozmozhnosti graficheskogo
interfejsa v neobhodimom dlya svoego prilozheniya napravlenii.
Blagodarya gibkim vozmozhnostyam kross-platformennoj svyazi,
prilozheniya Photon mogut byt' ispol'zovany prakticheski v lyuboj
nastol'noj srede.



Last-modified: Wed, 06 Mar 2002 08:50:13 GMT
Ocenite etot tekst:Ne chital10987654321