Geçmişte Executive i kernel in dış katmanı olarak tanımlamıştık. Bu aslında ntoskrnl.exe in dış katmanıdır. Gerçi sadece iç katmanına Kernel denir, ama günlük hayatımızda ntoskrnl.exe in hepsine Kernel deriz. Bu yanlış değil, ama farkı da unutmamak lazım. Executive de temel işletim sisteminin hizmet sağlayıcıları yer almaktadır. Burada örneğin process ve thread yönetimi, bellek yönetimi ve güvenlik açısından WD206 da söz edilen security reference monitör çalışır. Cacheleme yönetimi ve I/O sisteminin de kodlarını bu tarafta bulabiliriz. Kolaylık açısından kitapta sayfa 50 deki detaylı grafik bu yapıyı özlemektedir. Fark edeceksinizdir, burada sadece I/O manager diye bir yapı gösterilmektedir,


I/O system
diye bir bölüm yoktur. Bunun nedeni I/O sisteminin executive ve usermode tarafında çalışan farklı bileşenlerden oluşmasıdır: WDM WMI rutinlerine ihtiyacımız olur ve burada user mode tarafındaki WMI servisi de bunun bir parçasıdır. Ayrıca PnP manager bir bileşendir ve bunun da user mode tarafında çalışan komponentleri vardır. I/O sistemi ayrıca kernel mode ve user mode da çalışan komponentlerden oluşan power manager dan ve son olarak sadece executive de implemente edilmiş olan merkezi I/O manager dan oluşur.

Genişletilmiş bakış açısında I/O manager ında usermode komponentleri olabilir. Bunlar örneğin bir IO aygıt sürücüsü yüklenirken kullanılan user modedaki setup ile ilgili bileşenler olabilir. Yani genişletilmiş bakış açısından örneğin bu tarz kurulumlarda kullanılan .inf ve .cat dosyaları da I/O sisteminin yapısal ihtiyaçları için gereklidir ve kendisini bütünleyen parçaları olarak görülebilir. O zaman registry de dahil olur ve tabii ki aygıt sürücülerin kendileri de burada yer alır.

Son olarak işletim sisteminin bütün donanım ile ilgili yapısının altında duran ve işletim sisteminin geniş çaplı donanımsal uyumluluğunu sağlayabilmek için ‘donanımsal abstraksiyon’ yapan HAL da bunun bir parçasıdır. Bunun sayesinde bütün donanımsal detayları bilmeden Windows API leri kullanarak aygıt sürücüsü yazma imkânımız oluşur. Bu yapı sayfa 539 da bir grafik aracılığı ile özetlenmektedir.


Şimdi, executive yapısının içindeki I/O system in bileşenlerini çıkardık. Konsepti biraz daha genel anlayabilmek için bileşenlerin görevlerini tanımlayabiliriz.

Burada bütün IO interaksiyonların merkezinde I/O Manager yer alır. Yüklenen aygıt sürücüleri kendilerini burada kayıt ederler. Burası her şeyin birleştiği noktadır ve bütün işlemler nereden gelip nereye gitse de, bu noktaya dokunmak zorundadırlar. Çünkü, buradaki çevirmeler sayesinde yazımlar ve sistem parçaları sanal, mantıksal ve fiziki aygıtlar ile buluşurlar. Burası Windows I/O frameworkün çekirdeğidir ve aygıt sürücülerin en temel I/O gereksinimlerinin uyarlandığı bölgedir.
Aygıtların güç seviye işlemlerinden sorumlu Power Manager dır. PnP Manager aygıtların sisteme eklenme ve çıkartılmalarını algılamaktan ve gerekli sürücülerin yüklenilmesinden sorumludur. Örneğin bir aygıtın uygun sürücüsü bulunamadığında, user mode tarafındaki PnP Manager servisini devreye alır ve otomatik sürücü yüklenmesi gerçekleşebilir. PnP Manager ın özelliği Bus tipi aygıt sürücüleri ile çalışmasıdır. Bus tipi sürücüsünün farkı kitabın 2ci bölümünden ve WD202 den hatırlayabileceğiniz gibi, aygıt sürücünün çalıştığı aygıtın altında, PCMCIA veya USB de olduğu gibi, çocuk aygıtı olmasıdır. Örneğin bir USB port una bağlı olan harici diskiniz gibi. Bus, port ve disk sürücüleri ayrıdır. Aygıt sürücü tiplerinin temel özetini sayfa 69 da ve daha detaylı bir özetini sayfa 542 de bulabilirsiniz.

WDM WMI yapısının temel görevi, sürücülerin WMI üzerinden user mode tarafındaki WMI servisi ile görüşebilmelerini sağlamaktır. Böylece sürücüler kendilerini WMI frameworküne WMI provider olarak dâhil edebilirler.

Son olarak aygıt sürücüsü de aslında sadece aygıt ile I/O manager arasındaki ara yüzdür. I/O manager sayesinde gerekli bütün aygıt sürücüler bir IO ya dâhil edilir. Bunlar IO komutlarını aygıta aktarırlar ve bitişinde yine I/O manager a geri bildirimde bulunurlar.


IO un kendisine baktığımızda: Windows un uyarladığı çoğu IO, IRP (I/O request packet) yapısı kullanılarak yapılmaktadır. IRP yapısı bir IO un başarılı sonuçlanabilmesi için gerekli tüm bilgileri içerir. I/O manager bu yapıyı oluşturduktan sonra basitçe ilişkin sürücüye bir pointer ı pass eder. Bu pointer ı referans noktası olarak kullanan sürücünün kodu, işlemlerini bitirdikten sonra yine durmun yönetimi I/O manager a aktarılır. Bu aşamada IRP sonlandırılabilir veya I/O manager gerekli bir sonraki sürücüyü dâhil edebilir. IRP bir alış veriş listesine, bir yemek tarifine benzetilebilir. Belli bir yemeği yapmak istiyorsanız, belli içeriklere ve bunların işlemelerini tarif eden belli izleklere ihtiyacınız olur. Bir IO yapıyorsanız da bütün ilgili sürücüleri dâhil etmeniz gerekir.
Bir alışveriş listesi, kendilerini belli bir IO türü için IO manager a register etmiş olan sürücü listesine benzetilebilir. Bunların hepsini dahil etmeden IO yu yapamayız. Yemek tarifini de sürücülere bölünmüş olarak düşünebiliriz. Her sürücü sıra kendisine geldiğinde kendisine düşen izlekleri tamamlar. Burada örneğin tarama yapmak isteyen antivirüsün sürücüsü ve storage sürücüsü devreye girebilir. Sırayla bütün sürücüler IO paketine erişirler ve istedikleri değişiklikleri yaparlar. IO manager a sürücüler kendilerini register ederken, zaten hangi senaryolarda işletim sisteminin kendilerinin hangi kodunu çalıştıracağını belirlerler.

Bu belli kod ofsetlerine routine denilir. Örneğin kullanıcı kopyalama işleminde cancel de edebilir. Her sürücüsünün bir cancel routine i vardır ve sürücü kendisini IO manager a kayıt ederken bu bilgiye de kayıt eder. Kısaca: cancel durumunda bu offsetimindeki bu fonksiyonuma pointer ı pass et. WD203 de Interrupt Service routine den söz edilmişti. Bir aygıt processörü interrupt ettiğinde kerneldeki interrupt dispatcherı ilgili sürücünün bu ISR ını devreye alır. Yani, senin aygıtından, deviceobjectinden interrupt geldi, sen devicedriverı sın ve bu durumumda senin interrupt service routinine ine bu pointerı pass ediyorum. Bu durumda yapılacakların kodu bana daha önce bildirdiğin gibi burada. Yani genel olarak bir sürücü kernelde ‘serbest gezmez’, ne zaman nasıl devreye alınmasını kurulurken bildirir ve bu belli kodlar istenilen durumlarda kernel tarafından devreye alınır. Yani bu kodlar, sürücünün kendisi kernelin bir parçası olur.
Ve önceki bölümlerden hatırlamıyorsanız, neden pointer? Windows un çoğu C de yazılmıştır. Teoride bir sürücü kendisini her türlü IO a dâhil ettirebilir ve IO paketine değişiklik yapabilir.


Böylece işletim sistemi açısından bütün IO detaylarını bilmemize gerek kalmaz. İşletim sistemi I/O sistemi sayesinde sadece bir aygıta IO yapmak isteyen yazılım ile ilgili aygıtı ve sürücülerini birleştirir (device object ve driver object s. 554). Bunu yaparken kullandığı paket yapısı sayesinde de bir threadin birçok IO yu simultane yapabilmesini mümkün kılar.


I/O Sistemi ne kadar geniş kapsamlı olsa da, illa sadece tek başına bir IO esnasında gerekli bütün işlemleri yapamaz. Örneğin WD206 da güvenlik için dediğimiz gibi, güvenlik yapısı sürekli her işlemde çalışan bir yapıdır. Bu bir hizmettir ve sistemdeki her şey bundan faydalanabilir ve buna tabi tutulur. Ondan da executive bulabildiğimiz bu yapılara ‘işletim sisteminin hizmet sağlayıcıları’ diyebiliriz. Yaygın olarak bunlara rutin de demekteyiz. Güvenlik için security reference monitör örneğin file IO sunda ACL lerin kontrolü için dâhil olur. I/O sistemi de işletim sisteminin sadece bir parçası olduğundan, izole çalışamaz ve diğer executive rutinleri kullanır.


I/O system
in konseptini ve çalışma temellerini özetledikten sonra değişik IO türevlerine bakabiliriz.

Örneğin işletim sistemi mapped file I/O özelliğini sunar. Bu IRP yapısını kullanmaz. Burada disk de duran bir dosya bir processin sanal adres bölgesine maplenir. Diskde duran dosya RAM de durabildiği için, bunun avantajı elbet hızdır ve bu şekilde işletim sistemi cacheleme özelliğini de kazanmış olur. Bunu I/O systemi memory manager ın yardımı ile gerçekleştirir.


IO genel olarak Synchronous ve Asynchronous olarak bölünür. Synchronous ReadFile ve WriteFile gibi kernel fonksiyonlarda yapılan IO dur. Yani yazılım eşleme gereği IO un bitmesini bekler. Asynchronous da yazılım akışı devam eder ve IO un bitmesi beklenmez.
Bütün bu sistemin çalışabilmesi için de bir aygıt sürücüsüne yönelik temel gereksinimler mevcuttur. Bunların detaylı listesini sayfa 548 de bulabilirsiniz.


Genel olarak bir buffer bir işlem esnasında bir veri için geçici kullanılan bir bellek alanıdır. Örneğin eskiden arabalardaki CD playerlar media oynatırken aracın sallanmasında ses gidebiliyordu. Laser titreşimden dolayı optic mediumdaki pathini kaybedebiliyordu ve yine mediumdan okunabildiğinde ses geri geliyordu. Buradaki çözüm bir buffer. Yani mediumdan okunan verilerin ses aygıtına aktarılmadan bir ara bellek de depolanması. Böylece mediumdan okuyamayınca sadece belleğe depolama işlemi geçici durdurulmuş oluyor, bellekten ama veriler hala ses aygıtına iletilebiliyor.

IO verisinin IRP oluştururken işletim sistemi nasıl buffer layacağını bilmeli. Buffered I/O da, çağıranın bufferından veri kernelin non paged pool da bu IO için oluşturulan eşit boyutlu bir buffer a kopyalanır. Okumada da veri (aygıttan) non paged pool daki buffer üzerinden çağıranın bufferına kopyalanır. IRP sonlandığında non paged pool daki buffer alanı da serbest bırakılır. Direct I/O da callerın bufferını kilitleyip bunu RAM e mapleriz. Örneğin DMA, direct memory Access yapabilen sürücüler ile bu şekilde çalışılır: RAMe yüklenmiş buffer alanı MDL, memory desriptor list ile tarif edilir ve sürücü bu bilgileri aygıta yönlendirir. Böylece donanımsal altyapının sunduğu imkân ile DMA ın en büyük özelliği mümkün olur: CPU devreye alınmadan, aygıt direk bellek ile çalışabilir. İşletim sistemi iki buffer türünü de yapmamaya karar verebilir. Örneğin aygıt sürücüsü buffer lamayı kendisi yönetiyor olabilir.


Kendi IO aygıt sürücünüzü yazacaksanız kitabın 7 bölümü çok daha derin kavram ve gereksinimleri özetliyor. İşletim sisteminin IO altyapısı Windows Internals 5th ed. Chapter 7 ‘I/O System’ de anlatılmaktadır: http://technet.microsoft.com/en-us/sysinternals/bb963901

Ayrıca Windows internals ın 6th ed. ilk bölümü de piyasaya sunuldu:
http://technet.microsoft.com/en-us/sysinternals/bb963901

Başar Güner
Sr. Support Engineer, Microsoft