Windows Debugging 207
Geçmiste Executive i kernel in dis katmani olarak tanimlamistik. Bu aslinda ntoskrnl.exe in dis katmanidir. Gerçi sadece iç katmanina Kernel denir, ama günlük hayatimizda ntoskrnl.exe in hepsine Kernel deriz. Bu yanlis degil, ama farki da unutmamak lazim. Executive de temel isletim sisteminin hizmet saglayicilari yer almaktadir. Burada örnegin process ve thread yönetimi, bellek yönetimi ve güvenlik açisindan WD206 da söz edilen security reference monitör çalisir. Cacheleme yönetimi ve I/O sisteminin de kodlarini bu tarafta bulabiliriz. Kolaylik açisindan kitapta sayfa 50 deki detayli grafik bu yapiyi özlemektedir. Fark edeceksinizdir, burada sadece I/O manager diye bir yapi gösterilmektedir,
I/O system diye bir bölüm yoktur. Bunun nedeni I/O sisteminin executive ve usermode tarafinda çalisan farkli bilesenlerden olusmasidir: WDM WMI rutinlerine ihtiyacimiz olur ve burada user mode tarafindaki WMI servisi de bunun bir parçasidir. Ayrica PnP manager bir bilesendir ve bunun da user mode tarafinda çalisan komponentleri vardir. I/O sistemi ayrica kernel mode ve user mode da çalisan komponentlerden olusan power manager dan ve son olarak sadece executive de implemente edilmis olan merkezi I/O manager dan olusur.
Genisletilmis bakis açisinda I/O manager inda usermode komponentleri olabilir. Bunlar örnegin bir IO aygit sürücüsü yüklenirken kullanilan user modedaki setup ile ilgili bilesenler olabilir. Yani genisletilmis bakis açisindan örnegin bu tarz kurulumlarda kullanilan .inf ve .cat dosyalari da I/O sisteminin yapisal ihtiyaçlari için gereklidir ve kendisini bütünleyen parçalari olarak görülebilir. O zaman registry de dahil olur ve tabii ki aygit sürücülerin kendileri de burada yer alir.
Son olarak isletim sisteminin bütün donanim ile ilgili yapisinin altinda duran ve isletim sisteminin genis çapli donanimsal uyumlulugunu saglayabilmek için ‘donanimsal abstraksiyon’ yapan HAL da bunun bir parçasidir. Bunun sayesinde bütün donanimsal detaylari bilmeden Windows API leri kullanarak aygit sürücüsü yazma imkânimiz olusur. Bu yapi sayfa 539 da bir grafik araciligi ile özetlenmektedir.
Simdi, executive yapisinin içindeki I/O system in bilesenlerini çikardik. Konsepti biraz daha genel anlayabilmek için bilesenlerin görevlerini tanimlayabiliriz.
Burada bütün IO interaksiyonlarin merkezinde I/O Manager yer alir. Yüklenen aygit sürücüleri kendilerini burada kayit ederler. Burasi her seyin birlestigi noktadir ve bütün islemler nereden gelip nereye gitse de, bu noktaya dokunmak zorundadirlar. Çünkü, buradaki çevirmeler sayesinde yazimlar ve sistem parçalari sanal, mantiksal ve fiziki aygitlar ile bulusurlar. Burasi Windows I/O frameworkün çekirdegidir ve aygit sürücülerin en temel I/O gereksinimlerinin uyarlandigi bölgedir.
Aygitlarin güç seviye islemlerinden sorumlu Power Manager dir. PnP Manager aygitlarin sisteme eklenme ve çikartilmalarini algilamaktan ve gerekli sürücülerin yüklenilmesinden sorumludur. Örnegin bir aygitin uygun sürücüsü bulunamadiginda, user mode tarafindaki PnP Manager servisini devreye alir ve otomatik sürücü yüklenmesi gerçeklesebilir. PnP Manager in özelligi Bus tipi aygit sürücüleri ile çalismasidir. Bus tipi sürücüsünün farki kitabin 2ci bölümünden ve WD202 den hatirlayabileceginiz gibi, aygit sürücünün çalistigi aygitin altinda, PCMCIA veya USB de oldugu gibi, çocuk aygiti olmasidir. Örnegin bir USB port una bagli olan harici diskiniz gibi. Bus, port ve disk sürücüleri ayridir. Aygit sürücü tiplerinin temel özetini sayfa 69 da ve daha detayli bir özetini sayfa 542 de bulabilirsiniz.
WDM WMI yapisinin temel görevi, sürücülerin WMI üzerinden user mode tarafindaki WMI servisi ile görüsebilmelerini saglamaktir. Böylece sürücüler kendilerini WMI frameworküne WMI provider olarak dâhil edebilirler.
Son olarak aygit sürücüsü de aslinda sadece aygit ile I/O manager arasindaki ara yüzdür. I/O manager sayesinde gerekli bütün aygit sürücüler bir IO ya dâhil edilir. Bunlar IO komutlarini aygita aktarirlar ve bitisinde yine I/O manager a geri bildirimde bulunurlar.
IO un kendisine baktigimizda: Windows un uyarladigi çogu IO, IRP (I/O request packet) yapisi kullanilarak yapilmaktadir. IRP yapisi bir IO un basarili sonuçlanabilmesi için gerekli tüm bilgileri içerir. I/O manager bu yapiyi olusturduktan sonra basitçe iliskin sürücüye bir pointer i pass eder. Bu pointer i referans noktasi olarak kullanan sürücünün kodu, islemlerini bitirdikten sonra yine durmun yönetimi I/O manager a aktarilir. Bu asamada IRP sonlandirilabilir veya I/O manager gerekli bir sonraki sürücüyü dâhil edebilir. IRP bir alis veris listesine, bir yemek tarifine benzetilebilir. Belli bir yemegi yapmak istiyorsaniz, belli içeriklere ve bunlarin islemelerini tarif eden belli izleklere ihtiyaciniz olur. Bir IO yapiyorsaniz da bütün ilgili sürücüleri dâhil etmeniz gerekir.
Bir alisveris listesi, kendilerini belli bir IO türü için IO manager a register etmis olan sürücü listesine benzetilebilir. Bunlarin hepsini dahil etmeden IO yu yapamayiz. Yemek tarifini de sürücülere bölünmüs olarak düsünebiliriz. Her sürücü sira kendisine geldiginde kendisine düsen izlekleri tamamlar. Burada örnegin tarama yapmak isteyen antivirüsün sürücüsü ve storage sürücüsü devreye girebilir. Sirayla bütün sürücüler IO paketine erisirler ve istedikleri degisiklikleri yaparlar. IO manager a sürücüler kendilerini register ederken, zaten hangi senaryolarda isletim sisteminin kendilerinin hangi kodunu çalistiracagini belirlerler.
Bu belli kod ofsetlerine routine denilir. Örnegin kullanici kopyalama isleminde cancel de edebilir. Her sürücüsünün bir cancel routine i vardir ve sürücü kendisini IO manager a kayit ederken bu bilgiye de kayit eder. Kisaca: cancel durumunda bu offsetimindeki bu fonksiyonuma pointer i pass et. WD203 de Interrupt Service routine den söz edilmisti. Bir aygit processörü interrupt ettiginde kerneldeki interrupt dispatcheri ilgili sürücünün bu ISR ini devreye alir. Yani, senin aygitindan, deviceobjectinden interrupt geldi, sen devicedriveri sin ve bu durumumda senin interrupt service routinine ine bu pointeri pass ediyorum. Bu durumda yapilacaklarin kodu bana daha önce bildirdigin gibi burada. Yani genel olarak bir sürücü kernelde ‘serbest gezmez’, ne zaman nasil devreye alinmasini kurulurken bildirir ve bu belli kodlar istenilen durumlarda kernel tarafindan devreye alinir. Yani bu kodlar, sürücünün kendisi kernelin bir parçasi olur.
Ve önceki bölümlerden hatirlamiyorsaniz, neden pointer? Windows un çogu C de yazilmistir. Teoride bir sürücü kendisini her türlü IO a dâhil ettirebilir ve IO paketine degisiklik yapabilir.
Böylece isletim sistemi açisindan bütün IO detaylarini bilmemize gerek kalmaz. Isletim sistemi I/O sistemi sayesinde sadece bir aygita IO yapmak isteyen yazilim ile ilgili aygiti ve sürücülerini birlestirir (device object ve driver object s. 554). Bunu yaparken kullandigi paket yapisi sayesinde de bir threadin birçok IO yu simultane yapabilmesini mümkün kilar.
I/O Sistemi ne kadar genis kapsamli olsa da, illa sadece tek basina bir IO esnasinda gerekli bütün islemleri yapamaz. Örnegin WD206 da güvenlik için dedigimiz gibi, güvenlik yapisi sürekli her islemde çalisan bir yapidir. Bu bir hizmettir ve sistemdeki her sey bundan faydalanabilir ve buna tabi tutulur. Ondan da executive bulabildigimiz bu yapilara ‘isletim sisteminin hizmet saglayicilari’ diyebiliriz. Yaygin olarak bunlara rutin de demekteyiz. Güvenlik için security reference monitör örnegin file IO sunda ACL lerin kontrolü için dâhil olur. I/O sistemi de isletim sisteminin sadece bir parçasi oldugundan, izole çalisamaz ve diger executive rutinleri kullanir.
I/O system in konseptini ve çalisma temellerini özetledikten sonra degisik IO türevlerine bakabiliriz.
Örnegin isletim sistemi mapped file I/O özelligini sunar. Bu IRP yapisini kullanmaz. Burada disk de duran bir dosya bir processin sanal adres bölgesine maplenir. Diskde duran dosya RAM de durabildigi için, bunun avantaji elbet hizdir ve bu sekilde isletim sistemi cacheleme özelligini de kazanmis olur. Bunu I/O systemi memory manager in yardimi ile gerçeklestirir.
IO genel olarak Synchronous ve Asynchronous olarak bölünür. Synchronous ReadFile ve WriteFile gibi kernel fonksiyonlarda yapilan IO dur. Yani yazilim esleme geregi IO un bitmesini bekler. Asynchronous da yazilim akisi devam eder ve IO un bitmesi beklenmez.
Bütün bu sistemin çalisabilmesi için de bir aygit sürücüsüne yönelik temel gereksinimler mevcuttur. Bunlarin detayli listesini sayfa 548 de bulabilirsiniz.
Genel olarak bir buffer bir islem esnasinda bir veri için geçici kullanilan bir bellek alanidir. Örnegin eskiden arabalardaki CD playerlar media oynatirken aracin sallanmasinda ses gidebiliyordu. Laser titresimden dolayi optic mediumdaki pathini kaybedebiliyordu ve yine mediumdan okunabildiginde ses geri geliyordu. Buradaki çözüm bir buffer. Yani mediumdan okunan verilerin ses aygitina aktarilmadan bir ara bellek de depolanmasi. Böylece mediumdan okuyamayinca sadece bellege depolama islemi geçici durdurulmus oluyor, bellekten ama veriler hala ses aygitina iletilebiliyor.
IO verisinin IRP olustururken isletim sistemi nasil buffer layacagini bilmeli. Buffered I/O da, çagiranin bufferindan veri kernelin non paged pool da bu IO için olusturulan esit boyutlu bir buffer a kopyalanir. Okumada da veri (aygittan) non paged pool daki buffer üzerinden çagiranin bufferina kopyalanir. IRP sonlandiginda non paged pool daki buffer alani da serbest birakilir. Direct I/O da callerin bufferini kilitleyip bunu RAM e mapleriz. Örnegin DMA, direct memory Access yapabilen sürücüler ile bu sekilde çalisilir: RAMe yüklenmis buffer alani MDL, memory desriptor list ile tarif edilir ve sürücü bu bilgileri aygita yönlendirir. Böylece donanimsal altyapinin sundugu imkân ile DMA in en büyük özelligi mümkün olur: CPU devreye alinmadan, aygit direk bellek ile çalisabilir. Isletim sistemi iki buffer türünü de yapmamaya karar verebilir. Örnegin aygit sürücüsü buffer lamayi kendisi yönetiyor olabilir.
Kendi IO aygit sürücünüzü yazacaksaniz kitabin 7 bölümü çok daha derin kavram ve gereksinimleri özetliyor. Isletim sisteminin IO altyapisi Windows Internals 5th ed. Chapter 7 ‘I/O System’ de anlatilmaktadir: https://technet.microsoft.com/en-us/sysinternals/bb963901
Ayrica Windows internals in 6th ed. ilk bölümü de piyasaya sunuldu:
https://technet.microsoft.com/en-us/sysinternals/bb963901
Basar Güner
Sr. Support Engineer, Microsoft