#02 Hizmetler, sistem çağrıları ve çekirdek yapıları

Aşağıda defterde yazılan bütün satırlar ve bunlara eşlik eden sesli anlatımın tam metni bulunur.

1. 1. Bir hizmeti nasıl isteriz?

   

   Geçen ders: paylaştır · soyutla · koru

   Bugün: hizmet → sistem çağrısı → çekirdek

   Sesli anlatım metni

   Geçen derste işletim sisteminin kaynakları paylaştırdığını, ayrıntıları soyutladığını ve erişimi sınırladığını gördük. Bugün uygulamanın bir hizmeti nasıl istediğini ve çekirdeğin nasıl düzenlenebildiğini açacağız. Dosyayı aç dediğinizde donanıma doğrudan mı gidiyoruz, yoksa kontrollü bir kapıdan mı geçiyoruz? Bu kapıya sistem çağrısı diyoruz.

2. 2. Kaydet düğmesi, görünmeyen bir istek zinciri

   

   Mavi: uygulama · Mor: çekirdek

   “Düğme doğrudan diski mi yönetiyor?”

   Resepsiyon: istek → kontrol → sonuç

   Başarı kadar hata dönüşü de sözleşmenin parçasıdır.

   Sesli anlatım metni

   Bir sıcaklık kaydı uygulaması düşünün. Sensörden gelen kayıtları ekranda çiziyor ve günlüğe ekliyor. Renkleri ayıralım: uygulama mavi, ayrıcalıklı çekirdek mor, başarılı dönüş yeşil. Kaydet düğmesine bastınız. İlk içgüdü şu olabilir: düğmenin kodu diskteki her şeyi doğrudan yönetiyordur. Oysa uygulama önce bir yazılım hizmeti ister. Bir otelin resepsiyonunu düşünün. Odaya anahtar istemek, anahtar dolabındaki bütün odalara erişim vermek değildir. İstek alınır, kimlik ve yetki denetlenir, uygun sonuç döner. Bu benzetme çekirdeğin tamamını açıklamaz; kontrollü hizmet fikrini kurar. Bir çağrı başarısız da olabilir. İzin reddedilirse uygulama bunu işleyebilmelidir. Bugünün sorusu, bu sınırın iki tarafında hangi işin yürüdüğüdür.

3. 3. İşletim sisteminin hizmet haritası

   

   Program yürütme

   Girdi / çıktı ve dosya yönetimi

   İletişim ve hata algılama

   Kaynak ayırma · kayıt · koruma

   Arayüz, hizmetin görünen girişidir.

   Sesli anlatım metni

   Hizmetleri dosya okumaya indirgemeyelim. Program yürütme hizmeti, programı yüklemek ve yürütmeyi başlatmakla ilgilidir. Girdi çıktı hizmeti aygıtlarla veri alışverişini sağlar. Dosya yönetimi, dosyaları ve dizinleri adlarıyla açmayı, okumayı ve değiştirmeyi mümkün kılar. İletişim hizmetleri süreçlerin bilgi alışverişine yardım eder. Hata algılama, yanlış bir erişimi ya da başarısız aygıt işlemini fark edip uygun tepki vermektir. Kaynak ayırma işlemciyi, belleği ve aygıtları paylaştırır. Kayıt tutma, kullanımı izler. Koruma, bir kaynağa kimin erişebileceğini denetler. Güvenlik daha geniş bir konudur; dış tehditlere karşı savunmayı da içerir. Bütün bunların üstünde farklı kullanıcı arayüzleri olabilir. Komut satırı, dokunmatik ekran ve masaüstü aynı hizmetlere farklı yollardan ulaşabilir. Arayüzü değiştirmek, çekirdeğin bütün işlerini değiştirmek demek değildir.

4. 4. API ile sistem çağrısını ayır

   

   API: uygulama programlama arayüzü

   Kütüphane işlevi ≠ tek sistem çağrısı

   Kontrollü geçiş ve parametre denetimi

   Mod geçişi ≠ süreç değişimi

   Parametre aktarımı mimariye bağlıdır.

   Sesli anlatım metni

   Programcı çoğu zaman doğrudan işlemciye özgü çağrı komutu yazmaz. Bir uygulama programlama arayüzü, yani ey pi ay kullanır. Bu arayüz, hangi parametrenin verileceğini ve hangi sonucun alınacağını tanımlar. Kütüphane işlevi gerekirse gerçek sistem çağrısını yapar. Bu nedenle her kütüphane işlevi bir sistem çağrısı değildir. Bazı işler kullanıcı alanında tamamlanır; bazıları birden fazla çağrı gerektirebilir. Çağrı gerektiğinde uygulama isteği ve parametreleri hazırlar. Donanımın kontrollü geçiş mekanizması yürütmeyi çekirdek modundaki uygun işleyiciye götürür. Çekirdek parametreyi, bellek erişimini ve yetkiyi denetler. Sonunda veri ya da hata durumu uygulamaya döner. Bu sırada süreç başka bir sürece dönüşmek zorunda değildir. Mod değişimi ile süreçler arasında bağlam değiştirme ayrı olaylardır. Parametreler mimariye göre yazmaçlarla, bellek içindeki bir yapıyla ya da yığın üzerinden aktarılabilir. Bunlar aktarım mekanizmalarıdır; bugün belirli bir mimarinin çağrı sözleşmesini ezberlemiyoruz.

5. 5. İstek büyüklüğü ile sonuç büyüklüğü farklıdır

   

   İstenen üst sınır: 8 bayt

   Gerçekte dönen: 5 bayt

   Kalan talep: 8 − 5 = 3 bayt

   Kontrol: dönen miktar talep sınırını aşmaz.

   Sözleşmeyi izle; başarıyı varsayma.

   Sesli anlatım metni

   Günlüğü okumak için bir çağrı yaptığımızı düşünelim. Bu, belirli bir işletim sistemi komutu değil, okuma sözleşmesinin öğretim modelidir. İstenen üst sınır sekiz bayt olsun. Başarılı çağrı bu örnekte beş bayt döndürsün. Uygulama gerçekten dönen miktarı kullanır. Sekiz istedim, demek ki sekiz geldi varsayımı yanlıştır. Henüz istenen miktarın tamamı yoksa kalan miktarı hesaplarız. Sekiz eksi beş eşittir üç bayt. Ancak bu, mutlaka üç bayt daha gelecek garantisi değildir. Dosya sonu ya da hata, sonraki denemeyi değiştirebilir. Buradaki makullük kontrolü basit: başarıyla bildirilen miktar, sözleşmemizde talep edilen üst sınırı aşmamalı. Sonuç bilgisini görmezden gelmek, doğru hizmeti yanlış kullanmak olur. Gerçek kodda dosya sonunu, hata durumunu ve kısmi okumayı arayüzün belgelerine göre ele alırsınız. Sözleşmeyi bilmek, çekirdeğin içindeki aygıt kodunu bilmekten farklı bir beceridir.

6. 6. Aynı veri, daha az kontrollü giriş

   

   6 × 16 = 96 bayt

   Model: sabit giriş maliyeti 20 µs / çağrı

   Ayrı ayrı:

   $\displaystyle 6 \times 20 = 120 µs$

   Bir parti:

   $\displaystyle 1 \times 20 = 20 µs$

   Sabit maliyet tasarrufu:

   $\displaystyle 120 - 20 = 100 µs$

   Toplama verimi ile gecikme ihtiyacını tart.

   Sesli anlatım metni

   Şimdi özgün bir maliyet modeli kuralım. Altı bağımsız kayıt var. Her biri on altı bayt olsun. Toplam veriyi altı çarpı on altı ile buluruz: doksan altı bayt. Her kontrollü çağrının sabit giriş maliyetini yirmi mikrosaniye kabul edelim. Bu gerçek cihaz ölçümü değildir. Veri taşıma maliyetini iki yöntemde aynı sayıyor ve şimdilik hesap dışında tutuyoruz. Her kaydı ayrı çağrıyla yollarsak altı giriş olur. Altı çarpı yirmi, yüz yirmi mikrosaniye sabit maliyet eder. Kayıtlar birleştirilmeye uygunsa aynı veriyi tek çağrıda yollayabiliriz. Bir çarpı yirmi; tek giriş için yirmi mikrosaniye. Aradaki farkı çıkaralım: yüz yirmi eksi yirmi, yüz mikrosaniye. Veri miktarı azalmadı; kontrollü giriş sayısı azaldı. Bu, bütün programın altı kat hızlandığı anlamına gelmez. Ayrıca her kayıt acilse biriktirmek gecikme yaratabilir. Daha az çağrı bazen verimlidir; karar hizmetin anlamına ve gecikme ihtiyacına bağlıdır.

7. 7. Aynı hizmet, farklı iç yapı

   

   Monolitik: hizmetler aynı ayrıcalıklı alanda

   Katmanlı: tanımlı düzeyler ve arayüzler

   Mikroçekirdek: küçük merkez + ayrı hizmetler

   Tasarım seçimi: hız · bakım · yalıtım

   Sesli anlatım metni

   Çekirdeğin içindeki parçalar nasıl bağlanabilir? Monolitik yaklaşımda birçok temel hizmet aynı ayrıcalıklı adres alanında birlikte çalışır. İç iletişim kısa olabilir; fakat bir bileşendeki hata daha geniş etki yaratabilir. Katmanlı yaklaşım görevleri düzeylere böler. Bir düzey, alttaki düzeylerin tanımlı hizmetlerini kullanır. Bu, düşünmeyi ve sınamayı kolaylaştırabilir. Katmanları doğru ayırmak ve gereksiz geçişleri önlemek ise tasarım işidir. Mikroçekirdek yaklaşımı çekirdekte daha az temel mekanizma tutar. Bazı hizmetler ayrı kullanıcı alanı süreçlerine taşınır ve mesajlarla konuşur. Ayrım, hata yalıtımına yardım edebilir; iletişimin de bir maliyeti vardır. Bu çizimler birer tasarım fikridir; gerçek sistemler bunları çeşitli biçimlerde birleştirir. Hiçbir etiketi otomatik olarak en hızlı ya da en güvenli ilan etmiyoruz.

8. 8. Modül, mekanizma ve politika

   

   Modüler olmak, mikroçekirdek olmak değildir.

   Mekanizma: nasıl? · Politika: hangisi?

   Kararı, onu uygulayan araçtan ayır.

   Açık sorumluluk ve açık arayüz

   Sesli anlatım metni

   Modül yaklaşımı, çekirdeğin yeteneklerini tanımlı arayüzlü parçalarla genişletmeye yardım eder. Modüler bir çekirdek yine monolitik olabilir. Modül kelimesi, parçanın kullanıcı alanında çalıştığını tek başına söylemez. Bir de nasıl sorusu ile hangisi sorusunu ayıralım. Zamanlayıcıyı çağıran sayaç ve geçiş araçları mekanizmadır. Hangi hazır işe öncelik verileceği politikadır. Resepsiyon örneğinde anahtarı güvenli teslim etme düzeni mekanizma olsun. Önce hangi rezervasyona hizmet verileceği politikadır. Politika değiştiğinde bütün kapı sistemini yeniden kurmak istemezsiniz. Bu ayrım daha sonra işlemci zamanlamasında karşımıza çıkacak. Bugün bildiğimiz şey, çekirdek tasarımının yalnız kutuları küçültmek değil, sorumlulukları ve arayüzleri açık tanımlamak olduğudur.

9. 9. Bir hizmet isteğini okuyabilir misin?

   

   Soru: yetkisiz yazma isteğini kim denetler?

   Yanıt: çekirdek yetkiyi denetler.

   Bir API işlevi, çağrı sayısını kanıtlamaz.

   Partilemede aynı veri; daha az sabit giriş

   Sesli anlatım metni

   Kısa bir kontrol yapalım. Bir uygulama günlüğe kayıt yazmak istiyor; ama bu dosyaya yazma yetkisi yok. Hangi katman son kararı verir? Bir an düşünün. Çekirdek, ilgili koruma kurallarıyla isteği denetler ve hata sonucu döndürebilir. Ekrandaki düğmenin görünür olması yazma yetkisi vermez. Peki bir kütüphane işlevinin adını görmek, tek bir sistem çağrısı yapıldığını kanıtlar mı? Hayır. Arayüz ve gerçekleştirim arasındaki ayrımı hatırlayın. Son olarak partileme örneğimizde veri miktarı ne oldu? Aynı kaldı. Azalan, sabit giriş maliyetiydi. Maliyet modelinin kapsamını söylemeden bütün program için hız oranı çıkaramayız.

10. 10. Üç yanlış içgüdüyü düzelt

    

    Her işlev çekirdeğe girmez.

    Mod değişimi, süreç değişimi zorunluluğu değildir.

    Yapı etiketi tek başına performansı söylemez.

    İste → denetle → sonucu işle

    Sesli anlatım metni

    Birinci hata: her uygulama işlevi çekirdeğe girer. Hayır; kullanıcı alanında tamamlanan işler de vardır. Arayüzün adı tek başına giriş sayısını vermez. İkinci hata: mod değişince mutlaka başka süreç çalışır. Hayır; aynı süreç bir hizmet için çekirdeğe girip geri dönebilir. Bağlam değiştirmeyi sonraki derste ayrı ele alacağız. Üçüncü hata: mikroçekirdek her durumda daha hızlıdır. Hayır; ayrımın getirileri ve iletişim maliyetleri birlikte değerlendirilir. İhtiyacı ve gerçek ölçümü görmeden tasarımları sıralamayın. Akılda kalan kural şu: uygulama hizmet ister, çekirdek sözleşmeyi ve yetkiyi denetler, sonuç uygulamaya döner.

11. 11. Hizmetin sınırı, tasarımın sorumluluğu

    

    Uygulama → kontrollü hizmet → sonuç

    Hizmet · arayüz · çağrı · yapı

    Sonraki ders: süreçler ve bağlam değiştirme

    Sesli anlatım metni

    Modele dönelim. Uygulama mavi tarafta işini tanımlar. Mor çekirdek tarafı ortak kaynaklara kontrollü erişim sağlar. Yeşil dönüş, veriyi veya hata durumunu uygulamaya taşır. Hizmet ile arayüzü; arayüz ile gerçek sistem çağrısını; mekanizma ile politikayı ayırdık. Küçük günlük örneğinde istenen ve dönen miktarı denetledik, partilemenin yalnız sabit maliyeti nasıl etkilediğini gördük. Bir sonraki derste çalışan programı işletim sisteminin nasıl temsil ettiğini konuşacağız: süreç, süreç durumları ve bağlam değiştirme. Görüşmek üzere.

Kaynak video: Hizmetler, sistem çağrıları ve çekirdek yapıları (8:43)