``

Modül mimarisi nasıl çalışır?

Bir çekirdek modülü, kullanıcı alanındaki sıradan uygulamalardan farklı olarak kernel space içinde çalışır. İşletim sisteminin belleğine ve donanım kaynaklarına doğrudan erişebildiği için küçük bir hata bile tüm sistemi durdurabilir. Bu nedenle geliştirmeyi sanal makinede yapmak akıllıcadır.

Modül çekirdeğe yüklendiğinde sembolleri bağlanır, başlangıç fonksiyonu çalıştırılır ve gerekli kaynaklar kaydedilir. Kaldırılırken kaynakların ters sırada serbest bırakılması gerekir. Basitleştirilmiş yaşam döngüsü şöyledir:

Sağlıklı bir kaldırma işleminde sonucun $0$ olması beklenir. Aksi durumda bellek sızıntıları, kullanımda kalan cihazlar veya çökmeler ortaya çıkabilir.

Basit bir karakter cihazı

Aşağıdaki modül, /dev/minidriver adında bir karakter cihazı oluşturur. Kullanıcı cihazı okuduğunda çekirdekten kısa bir mesaj alır. miscdevice arabirimi, ana cihaz numarasını otomatik seçerek örneği sade tutar.

#include <linux/module.h>
#include <linux/miscdevice.h>
#include <linux/fs.h>
#include <linux/uaccess.h>

static const char message[] = "Merhaba, çekirdek!\n";

static ssize_t mini_read(struct file *file, char __user *buffer,
                         size_t length, loff_t *offset)
{
    return simple_read_from_buffer(buffer, length, offset,
                                   message, sizeof(message) - 1);
}

static const struct file_operations mini_fops = {
    .owner = THIS_MODULE,
    .read = mini_read,
};

static struct miscdevice mini_device = {
    .minor = MISC_DYNAMIC_MINOR,
    .name = "minidriver",
    .fops = &mini_fops,
    .mode = 0444,
};

static int __init mini_init(void)
{
    int result = misc_register(&mini_device);

    if (result)
        pr_err("minidriver kaydedilemedi: %d\n", result);
    else
        pr_info("minidriver yüklendi\n");

    return result;
}

static void __exit mini_exit(void)
{
    misc_deregister(&mini_device);
    pr_info("minidriver kaldırıldı\n");
}

module_init(mini_init);
module_exit(mini_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Örnek Geliştirici");
MODULE_DESCRIPTION("Basit karakter cihazı modülü");

file_operations, sistem çağrıları ile sürücü fonksiyonları arasındaki köprüdür. Kullanıcı read() çağırdığında çekirdek mini_read() fonksiyonuna yönelir. simple_read_from_buffer() ise çekirdek belleğindeki veriyi kullanıcı belleğine kontrollü şekilde aktarır; doğrudan işaretçi kopyalamaktan daha güvenlidir.

Derleme ve deneme

Modülü derlemek için aynı dizine şu Makefile dosyasını ekleyin:

obj-m += minidriver.o

all:
	$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	$(MAKE) -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Ardından geliştirme başlıklarının kurulu olduğundan emin olarak komutları çalıştırın:

make
sudo insmod minidriver.ko
cat /dev/minidriver
sudo rmmod minidriver
dmesg | tail

insmod modülü doğrudan yüklerken modprobe bağımlılıkları da çözer. Üretim sistemlerinde Secure Boot imzasız modülleri reddedebilir; ayrıca çekirdek API’leri sürümler arasında değişebilir.

Güvenli geliştirme alışkanlıkları

Her tahsisin karşılığında bir temizleme işlemi yazın, kullanıcıdan gelen uzunluk ve adreslere güvenmeyin, kilit gerektiren ortak verileri koruyun ve günlükleri dmesg üzerinden izleyin. Gerçek donanım sürücülerinde kesmeler, DMA, aygıt ağacı ve platform veri yolları devreye girer. Ancak temel ritim değişmez: kaydet, isteği işle, kaynakları eksiksiz bırak ve modülü kaldır.

``

eBPF tam olarak nedir?

eBPF, kullanıcı alanında hazırlanan programların Linux çekirdeğindeki belirli kancalara yüklenmesini sağlayan bir çalışma ortamıdır. İsmindeki BPF, tarihsel olarak “Berkeley Packet Filter” anlamına gelse de teknoloji bugün ağ paketlerinin çok ötesine uzanır: sistem çağrıları, süreçler, dosya erişimleri ve performans olayları da izlenebilir.

“Çekirdeğe dokunmadan” ifadesi, kodun çekirdek dışında çalıştığı anlamına gelmez. eBPF programı çekirdek bağlamında çalışır; ancak çekirdek kaynak kodunu değiştirmeye veya özel bir modül yüklemeye gerek bırakmaz. Program yüklenmeden önce verifier tarafından incelenir. Geçersiz bellek erişimi, güvensiz işaretçi kullanımı veya sonlanmama riski varsa program reddedilir.

XDP neden bu kadar hızlı?

XDP, yani eXpress Data Path, paketi ağ sürücüsünden gelir gelmez işleyebilir. Paket henüz sk_buff yapısına dönüştürülmeden karar verildiği için ayırma, kopyalama ve ağ yığını maliyetleri azaltılır.

Bir paketin yaklaşık işlem maliyetini şöyle düşünebiliriz:

XDP özellikle $T_{ayrıştırma}$ ve $T_{yönlendirme}$ bileşenlerini küçültür. Program paketi kabul etmek için XDP_PASS, düşürmek için XDP_DROP, başka arayüze göndermek için XDP_REDIRECT döndürebilir.

Aşağıdaki orta düzey örnek, IPv4 UDP paketlerini erken aşamada düşürür:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int drop_udp(struct xdp_md *ctx)
{
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    struct ethhdr *eth = data;

    if ((void *)(eth + 1) > data_end)
        return XDP_ABORTED;

    if (eth->h_proto != __constant_htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_ABORTED;

    return ip->protocol == IPPROTO_UDP ? XDP_DROP : XDP_PASS;
}

char LICENSE[] SEC("license") = "GPL";

Sınır kontrolleri yalnızca iyi programlama alışkanlığı değildir; verifier, data_end kontrolü bulunmayan paket erişimini kabul etmez. Kod Clang ile eBPF bytecode’una çevrilip bir arayüze bağlanabilir:

clang -O2 -g -target bpf -c filter.c -o filter.o
sudo ip link set dev eth0 xdp obj filter.o sec xdp
sudo ip link set dev eth0 xdp off

İlk komut programı derler, ikincisi eth0 arayüzüne yükler, sonuncusu ise bağlantıyı kaldırır. Uzaktan bağlı bir sunucuda bütün UDP trafiğini düşürmeden önce DNS ve VPN kullanımını düşünmek iyi fikirdir; aksi hâlde güvenlik demosu hızla bağlantı kesme demosuna dönüşebilir.

Haritalar ve gözlemlenebilirlik

eBPF haritaları, çekirdek ve kullanıcı alanı arasında paylaşılan anahtar-değer depolarıdır. IP başına paket sayacı tutmak, engelli adresleri dinamik olarak güncellemek veya CPU başına istatistik toplamak için kullanılabilirler. Üretimde C ile doğrudan uğraşmak yerine libbpf, BCC, bpftrace, Cilium ve Rust tabanlı Aya gibi araçlardan yararlanılabilir.

TC kancaları paket değişikliği ve trafik şekillendirme konusunda daha esnekken XDP mümkün olan en erken kararı hedefler. Sonuç olarak eBPF, klasik çekirdek modüllerinin bütün risklerini üstlenmeden çekirdek hızına yaklaşan, programlanabilir bir ağ güvenliği ve izleme katmanı sunar.

FUSE tam olarak nedir?

FUSE, yani Filesystem in Userspace, dosya sistemi mantığının kullanıcı alanında çalışan normal bir program tarafından uygulanmasını sağlayan Linux altyapısıdır. Uygulamalar yine open, read, write ve stat gibi standart sistem çağrılarını kullanır. Çekirdekteki FUSE sürücüsü bu istekleri bizim sürecimize iletir, cevabı alır ve uygulamaya döndürür.

Akış kabaca şöyledir:

1. Kullanıcı /mnt/ozel/merhaba.txt dosyasını okur.
2. İşletim sistemi isteği FUSE sürücüsüne gönderir.
3. FUSE, Python programımızdaki read() metodunu çağırır.
4. Metodun ürettiği veri kullanıcıya teslim edilir.

Bir işlemin toplam gecikmesini basitçe $T = T_{kernel} + T_{iletisim} + T_{uygulama}$ şeklinde düşünebiliriz. Kullanıcı alanına geçiş ek maliyet oluşturduğu için FUSE her senaryoda yerel dosya sistemleri kadar hızlı değildir; fakat geliştirme kolaylığı çoğu özel proje için daha değerlidir.

Python ile çalışan küçük bir örnek

Ubuntu tabanlı bir sistemde gerekli paketleri şu şekilde kurabiliriz:

sudo apt install fuse3 libfuse3-dev
python3 -m pip install fusepy
mkdir -p /tmp/benimfs

Aşağıdaki dosya sistemi yalnızca merhaba.txt isimli sanal bir dosya sunar. Dosyanın fiziksel diskte bulunması gerekmez; içerik Python tarafından anlık üretilir.

from fuse import FUSE, Operations
import errno
import os

class BenimFS(Operations):
    mesaj = b"Merhaba, bu veri sanal dosya sisteminden geliyor!\n"

    def getattr(self, path, fh=None):
        if path == "/":
            return {
                "st_mode": 0o40555,
                "st_nlink": 2
            }

        if path == "/merhaba.txt":
            return {
                "st_mode": 0o100444,
                "st_nlink": 1,
                "st_size": len(self.mesaj)
            }

        raise OSError(errno.ENOENT, os.strerror(errno.ENOENT))

    def readdir(self, path, fh):
        return [".", "..", "merhaba.txt"]

    def open(self, path, flags):
        if path != "/merhaba.txt":
            raise OSError(errno.ENOENT, "Dosya bulunamadı")
        if flags & (os.O_WRONLY | os.O_RDWR):
            raise OSError(errno.EACCES, "Dosya salt okunur")
        return 0

    def read(self, path, size, offset, fh):
        return self.mesaj[offset:offset + size]

if __name__ == "__main__":
    FUSE(BenimFS(), "/tmp/benimfs", foreground=True)

getattr() dosyanın türünü, izinlerini ve boyutunu bildirir. readdir() dizin listesini üretir. open() erişim kurallarını denetlerken read() istenen aralıktaki baytları döndürür. Programı python3 benimfs.py ile çalıştırdıktan sonra başka bir terminalde cat /tmp/benimfs/merhaba.txt komutu kullanılabilir. Ayırmak için fusermount3 -u /tmp/benimfs yeterlidir.

Tasarımda dikkat edilmesi gerekenler

Gerçek bir projede eşzamanlı erişim, önbellekleme, dosya tanıtıcıları, kullanıcı kimlikleri ve hata kodları hesaba katılmalıdır. read() metodunun tüm içeriği değil, yalnızca offset ile başlayan size baytı döndürmesi özellikle önemlidir. Aksi hâlde büyük dosyalarda beklenmedik sonuçlar oluşabilir.

FUSE; prototipler, eğitim araçları, arşiv görüntüleyicileri ve uzak depolama istemcileri için güçlü bir oyun alanıdır. Çekirdeğe dalmadan işletim sisteminin dosya soyutlamasını kullanabilir, hatta bir REST API’yi klasör ve dosyalardan oluşan doğal bir arayüze dönüştürebilirsiniz.

``

Page cache nedir?

İşletim sistemi, depolama aygıtındaki dosyaları doğrudan uygulamaların yönetmesine izin vermez. Uygulama bir dosya istediğinde çekirdek, veriyi belirli büyüklükteki bellek sayfaları hâlinde okur. Okunan sayfalar yalnızca programa verilmez; aynı zamanda RAM içindeki page cache alanında tutulur.

Aynı dosya yeniden istendiğinde çekirdek önce önbelleği kontrol eder. Gerekli sayfalar RAM’deyse diske erişmeden sonucu döndürür. Buna cache hit, verinin bulunamayıp diskten okunmasına ise cache miss denir.

Basitleştirilmiş toplam erişim süresi şöyle düşünülebilir:

Buradaki $H$, önbellek isabet oranıdır. $H$ değeri 1’e yaklaştıkça ortalama erişim süresi RAM hızına yaklaşır. Küçük görünen bir isabet oranı artışı bile yoğun dosya kullanan sunucularda büyük performans farkı yaratabilir.

“Boş RAM” neden gerçekten boş değildir?

Görev yöneticisinde RAM’in büyük bölümünün kullanıldığını görmek her zaman sorun anlamına gelmez. Modern işletim sistemleri kullanılmayan belleği boş bırakmak yerine dosya önbelleği olarak değerlendirir. Çünkü kullanılmayan RAM, performans açısından kaçırılmış bir fırsattır.

Bir uygulama daha fazla belleğe ihtiyaç duyduğunda önbellekteki temiz sayfalar kolayca bırakılabilir. Bu nedenle page cache, uygulamaların belleğini “çalmaz”; ihtiyaç ortaya çıkana kadar boş kapasiteyi ödünç alır.

Linux çıktılarındaki free, buff/cache ve özellikle available değerleri bu yüzden birlikte değerlendirilmelidir:

# Belleğin uygulamalar ve önbellek arasında nasıl dağıldığını gösterir.
free -h

# Bir dosyayı okuyarak gerçek süreyi ölçer.
time cat buyuk-dosya.bin > /dev/null

# Aynı komut ikinci kez çalıştırıldığında veri büyük olasılıkla cache'tedir.
time cat buyuk-dosya.bin > /dev/null

İkinci çalıştırmanın daha hızlı olması, dosyanın değiştiği veya cat programının özel bir numara yaptığı anlamına gelmez. İlk komut dosya sayfalarını RAM’e taşımış, ikinci komut ise hazır bulunan sayfaları kullanmıştır. Dosya RAM kapasitesinden büyükse veya sistem yoğun bellek baskısı altındaysa fark azalabilir.

Yazma işlemlerinde de görev alır mı?

Evet. Bir uygulama dosyaya yazdığında veri çoğu zaman önce bellekteki sayfalara aktarılır. Değiştirilmiş ve henüz diske gönderilmemiş sayfalara dirty page denir. Çekirdek bunları daha sonra toplu biçimde diske yazar. Böylece uygulama her küçük değişiklik için fiziksel disk işlemini beklemez.

Bu yaklaşım performansı artırsa da elektrik kesintisi gibi durumlarda henüz kalıcı depolamaya ulaşmamış veriler kaybolabilir. Veritabanları bu nedenle fsync benzeri çağrılarla kritik verinin diske ulaştığından emin olur.

Page cache her şeyi hızlandırır mı?

Page cache sihirli değildir. İlk okuma yine depolama aygıtının hızına bağlıdır. Çok büyük veri kümeleri önbelleğe sığmayabilir; başka uygulamalar da sık kullanılan sayfaları dışarı itebilir. Ayrıca bazı veritabanları ve özel uygulamalar, kendi önbelleklerini yönetmek için doğrudan I/O kullanabilir.

Yine de günlük kullanımda programların hızlı açılması, kaynak kodlarının çabuk derlenmesi ve aynı videonun tekrar akıcı oynatılması çoğunlukla bu görünmez yardımcı sayesinde gerçekleşir. Kısacası yüksek RAM kullanımı her zaman kötü değildir: İşletim sistemi belleği dosyalarla dolduruyorsa, RAM’iniz tembellik etmek yerine gelecekteki disk okumalarını hızlandırıyordur.

``

İşlemci neden önbelleğe ihtiyaç duyar?

CPU ile RAM aynı hızda çalışmaz. İşlemci bir komutu birkaç çevrimde tamamlayabilirken RAM erişimi yüzlerce çevrim sürebilir. Bu farkı azaltmak için işlemci ile RAM arasına küçük fakat hızlı önbellek katmanları yerleştirilir.

Aranan veri önbellekte bulunursa cache hit, bulunamazsa cache miss oluşur. Basitleştirilmiş ortalama erişim süresi şöyle düşünülebilir:

Burada $h$ cache hit oranıdır. RAM çok daha yavaş olduğundan, $h$ değerindeki küçük bir artış bile toplam süreyi ciddi biçimde azaltabilir.

Mekânsal ve zamansal yerellik

Önbellek RAM’den tek bir değişken getirmez; genellikle 64 baytlık bir cache line taşır. Bir elemana eriştiğimizde komşu elemanlar da gelir. Ardışık elemanları kullanmak mekânsal yerellik, aynı veriyi kısa süre içinde tekrar kullanmak ise zamansal yerellik sağlar.

C ve C++ gibi dillerde iki boyutlu diziler satır öncelikli saklanır. Bu nedenle döngü sırası önemlidir:

#define N 2048
int matrix[N][N];
long long toplam = 0;

// Cache dostu: Bellekte ardışık elemanlar okunur.
for (int i = 0; i < N; i++) {
    for (int j = 0; j < N; j++) {
        toplam += matrix[i][j];
    }
}

İç döngüde j değiştiği için matrix[i][j] elemanları art arda okunur. Döngüleri ters çevirmek ise her erişimde farklı bir satıra sıçrayabilir:

// Cache açısından zayıf: Büyük adımlarla bellekte gezinir.
for (int j = 0; j < N; j++) {
    for (int i = 0; i < N; i++) {
        toplam += matrix[i][j];
    }
}

Her iki kod da aynı matematiksel sonucu üretir ve zaman karmaşıklıkları $O(N^2)$ olur. Buna rağmen gerçek çalışma süreleri dramatik biçimde farklılaşabilir. Big-O, bellek erişim maliyetini tek başına anlatmaz.

Veri yapısının dizilişi: AoS ve SoA

Bir oyundaki parçacıkları düşünelim:

struct Parca {
    float x, y, z;
    float hiz;
    int renk;
};

struct Parca parcalar[1000000];

Bu yaklaşım Array of Structures (AoS) olarak adlandırılır. Yalnızca konumları güncelliyorsak kullanılmayan renk gibi alanlar da cache line içine taşınır. Alternatif Structure of Arrays (SoA) düzeninde alanlar ayrılır:

struct Parcalar {
    float x[1000000];
    float y[1000000];
    float z[1000000];
    float hiz[1000000];
    int renk[1000000];
};

Büyük veriyi bloklar hâlinde işlemek

Matris çarpımı gibi algoritmalarda veri L1 veya L2’ye sığmayabilir. Blocking ya da tiling, problemi önbelleğe sığan küçük parçalara ayırır:

const int B = 32;

for (int ii = 0; ii < N; ii += B)
    for (int kk = 0; kk < N; kk += B)
        for (int i = ii; i < ii + B; i++)
            for (int k = kk; k < kk + B; k++)
                sonuc[i] += matrix[i][k] * vektor[k];

Blok boyutu donanıma ve veri tipine göre ölçülerek seçilmelidir. Gereğinden büyük bloklar önbellekten taşar; çok küçük bloklar ise döngü yönetimi maliyetini artırır.

Sonuç olarak ardışık erişim, tekrar kullanılan veriyi yakın tutma, uygun veri düzeni ve bloklama cache hit oranını yükseltir. En doğru optimizasyon için tahminde bulunmak yerine perf, Valgrind Cachegrind veya işlemci performans sayaçlarıyla cache miss değerlerini ölçmek gerekir. Çünkü hızlı kod yalnızca daha az işlem yapan değil, işlemciyi verisiz bırakmayan koddur.

Cgroups neyi çözer?

Cgroups, süreçleri gruplandırır ve CPU, bellek, disk G/Ç ya da süreç sayısı gibi kaynakları bu gruplar üzerinden denetler. Namespace’ler bir konteynerin neyi görebildiğini, cgroups ise ne kadar tüketebildiğini belirler. Dolayısıyla ikisi tamamlayıcıdır: namespace izolasyon perdesiyken cgroups kaynak bütçesidir.

Bir grubun CPU kullanım oranı basitçe

ile düşünülebilir. Burada $Q$ izin verilen CPU süresi, $P$ ise periyottur. Örneğin cpu.max dosyasına 50000 100000 yazılması, grubun her 100 milisaniyede en fazla 50 milisaniye CPU kullanabilmesi, yani yaklaşık $R=0.5$ CPU kapasitesi anlamına gelir.

v1 neden yorucuydu?

Cgroups v1’de her denetleyici bağımsız bir hiyerarşiye bağlanabiliyordu. Aynı süreç CPU ağacında bir grupta, bellek ağacında başka bir grupta bulunabiliyordu. Esneklik gibi görünen bu model; Docker, systemd ve Kubernetes gibi araçlar aynı makinede çalıştığında yönetim karmaşasına, belirsiz yetki devrine ve tutarsız kaynak davranışlarına yol açıyordu.

Birleşik hiyerarşi nasıl çalışır?

v2 çoğunlukla /sys/fs/cgroup altında tek bir ağaç sunar. Bir sürecin kimliği cgroup.procs, kullanılabilir denetleyiciler cgroup.controllers, alt gruplara aktarılacak denetleyiciler ise cgroup.subtree_control üzerinden yönetilir.

# Sistemde etkin olan v2 denetleyicilerini gösterir.
cat /sys/fs/cgroup/cgroup.controllers

# Yeni bir uygulama grubu oluşturur.
sudo mkdir /sys/fs/cgroup/demo

# Kabuğun PID'sini gruba taşır.
echo $$ | sudo tee /sys/fs/cgroup/demo/cgroup.procs

v2’nin önemli kurallarından biri no internal process constraint ilkesidir. Kaynak denetleyicileri alt gruplara dağıtan bir cgroup, normalde aynı anda doğrudan süreç barındırmaz. Başka bir deyişle dallar organizasyon, yapraklar iş yükü içindir. Bu kural, ebeveyn ve çocuk gruplar arasında kaynak hesabının bulanıklaşmasını önler.

Bellek, CPU ve süreç sınırları

Bellek tarafında memory.max kesin tavanı, memory.high ise çekirdeğin agresif geri kazanım uygulamaya başlayacağı yumuşak eşiği ifade eder. Böylece uygulamayı anında öldürmeden önce baskı oluşturmak mümkündür. memory.current mevcut tüketimi gösterirken memory.events, OOM gibi olayları sayar.

# Kesin bellek limitini 512 MiB yapar.
echo 536870912 | sudo tee /sys/fs/cgroup/demo/memory.max

# Yaklaşık yarım CPU ve en fazla 100 süreç tanımlar.
echo '50000 100000' | sudo tee /sys/fs/cgroup/demo/cpu.max
echo 100 | sudo tee /sys/fs/cgroup/demo/pids.max

CPU paylaşım önceliği için v1’deki cpu.shares yerine daha anlaşılır bir aralığa sahip cpu.weight kullanılır. G/Ç denetimi de io.max ve io.weight gibi tutarlı adlarla sunulur.

Docker açısından anlamı

Docker’daki --memory, --cpus ve --pids-limit seçenekleri sonuçta bu dosyalara dönüştürülür. Modern systemd sürümleri de servisleri cgroup ağacında doğal olarak düzenler. Tek hiyerarşi sayesinde orkestratör, çalışma zamanı ve init sistemi aynı kaynak ağacını paylaşabilir; “bu süreci aslında kim yönetiyor?” bilmecesi büyük ölçüde ortadan kalkar.

Cgroups v2 yalnızca temizlenmiş bir arayüz değildir. Tutarlı muhasebe, güvenli yetki devri, gelişmiş bellek baskısı ve sade hiyerarşi sayesinde konteyner izolasyonunu daha sağlam bir çekirdek sözleşmesine dönüştürür. Kısacası v1 kaynaklara ayrı ayrı kilit vuruyordu; v2 ise bütün binaya düzenli bir erişim planı çiziyor.

Bilgisayarın güç düğmesine bastığınızda Linux doğrudan / dizinine koşmaz. Çekirdek belleğe yüklense bile gerçek kök dosya sistemine ulaşmak için disk denetleyicisi, dosya sistemi, RAID, LVM veya şifreleme sürücülerine ihtiyaç duyabilir. İşte initramfs, bu tavuk-yumurta problemini çözen, RAM üzerinde kurulmuş geçici ve küçük bir kullanıcı alanıdır. ``

Açılış zincirindeki yeri

Modern bir Linux açılışı kabaca şu sırayı izler:

1. BIOS veya UEFI donanımı hazırlar.
2. GRUB gibi önyükleyici çekirdeği ve initramfs arşivini RAM’e taşır.
3. Çekirdek donanımı algılar ve initramfs’i geçici kök olarak açar.
4. Initramfs içindeki /init programı gerekli hazırlıkları yapar.
5. Gerçek kök dosya sistemi bağlanır.
6. switch_root sonrasında systemd veya başka bir init sistemi başlatılır.

Toplam açılış süresini basitleştirerek şöyle düşünebiliriz:

Initramfs aşaması küçük görünür; ancak şifreli diskin parolasını bekliyorsa veya kayıp bir depolama aygıtını arıyorsa $T_{initramfs}$ ciddi biçimde büyüyebilir.

Initramfs gerçekte nedir?

Initramfs genellikle cpio biçiminde paketlenmiş ve gzip, xz ya da zstd ile sıkıştırılmış bir arşivdir. Önyükleyici bu arşivi RAM’e yükler; çekirdek de arşivi kendi sağladığı geçici rootfs üzerine açar. Dolayısıyla klasik anlamda biçimlendirilmiş bir RAM diski olmak zorunda değildir.

Bu ortamda BusyBox, udev, cryptsetup, LVM araçları, dosya sistemi yardımcıları ve çekirdek modülleri bulunabilir. Amaç masaüstü açmak değil, ana sisteme giden köprüyü kurmaktır.

Çekirdek neden tek başına yetmiyor?

Çekirdek bazı sürücüleri doğrudan içine gömülü taşıyabilir. Fakat her sürücüyü çekirdeğe kalıcı olarak eklemek onu büyütür ve esnekliği azaltır. Modüler yaklaşımda gerekli .ko dosyaları initramfs’e yerleştirilir. Örneğin kök bölümünüz NVMe üzerinde ve ext4 biçimindeyse NVMe denetleyicisi ile ext4 desteğinin gerçek köke ulaşılmadan önce hazır olması gerekir.

Şifreli bir LVM düzeninde süreç daha eğlencelidir: initramfs önce disk sürücüsünü yükler, ardından LUKS kapsayıcısını cryptsetup ile açar, LVM mantıksal birimlerini etkinleştirir ve ancak bundan sonra kök dosya sistemini bağlar. Ağ üzerinden NFS kökü kullanılıyorsa ağ kartı sürücüsü, IP yapılandırması ve NFS desteği de bu minik çantaya eklenir.

İçeriği nasıl inceleriz?

Dağıtıma göre dosya adı değişse de mevcut arşivi listelemek kolaydır:

# Çalışan çekirdeğe ait initramfs içeriğini listeler.
lsinitramfs /boot/initrd.img-$(uname -r) | less

Fedora ve RHEL ailesinde benzer inceleme lsinitrd ile yapılır. Debian veya Ubuntu üzerinde initramfs’i yeniden üretmek için:

# Kurulu tüm çekirdeklerin initramfs dosyalarını günceller.
sudo update-initramfs -u -k all

Dracut kullanan sistemlerde karşılığı çoğunlukla şöyledir:

# Mevcut çekirdek için initramfs'i zorla yeniden oluşturur.
sudo dracut --force

Bu komutlar özellikle yeni depolama sürücüsü eklediğinizde, kök bölüm yapısını değiştirdiğinizde veya açılışta gerekli modül arşive girmediğinde önemlidir.

Hata olduğunda ne görürüz?

Initramfs gerçek kökü bulamazsa sistem acil durum kabuğuna düşebilir; unable to find root device, ALERT! UUID does not exist veya LUKS aygıtına ilişkin hatalar görülebilir. Bu noktada cat /proc/cmdline, blkid, ls /dev ve dmesg komutları güçlü dedektif araçlarıdır. Yanlış UUID, eksik modül ya da hatalı çekirdek parametresi genellikle suçludur.

Kısacası initramfs, Linux açılışının sahne arkasındaki teknik ekip gibidir: dekoru kurar, kapıları açar, gerçek kökü sahneye çıkarır ve işi bittiğinde sessizce ortadan kaybolur.

``

İşlemci neden geleceği tahmin eder?

Bir işlemci bellekten veri beklerken yüzlerce saat çevrimi kaybedebilir. Bu nedenle modern çekirdekler sıra dışı yürütme ve spekülatif yürütme kullanır. Örneğin bir dallanmanın sonucu henüz hesaplanmadıysa dallanma tahmincisi geçmiş davranışlara bakarak hangi yolun seçileceğini tahmin eder.

Tahmin doğruysa zaman kazanılır. Yanlışsa spekülatif işlemlerin mimari sonuçları iptal edilir. Ancak kritik ayrıntı şudur: Önbelleğe alınan veri gibi mikromimari etkiler tamamen geri alınmayabilir.

Basitleştirilmiş performans fikri şöyledir:

Burada $p$ tahmin doğruluğudur. Yüksek doğruluk ciddi hız kazandırır; fakat yanlış yol üzerinde geçici olarak yürütülen komutlar güvenlik sınırlarına dokunabilir.

Önbellek nasıl muhbir olur?

İşlemci önbelleğindeki bir veriye erişmek ana belleğe erişmekten daha hızlıdır:

Saldırgan verinin kendisini göremese bile belirli bir bellek bölgesine erişimin kaç nanosaniye sürdüğünü ölçebilir. Hızlı yanıt, ilgili satırın önbellekte olduğunu düşündürür. Böylece gizli bir bayt, farklı önbellek satırlarından birini seçmek için kullanılır ve değer zamanlama ölçümleriyle tahmin edilir.

Aşağıdaki kod, savunmasız desenin kavramsal ve çalıştırılabilir bir örneğidir; tek başına gerçek bir veri sızdırma saldırısı değildir:

unsigned char public_data[16];
unsigned char probe[256 * 4096];
size_t public_size = 16;

unsigned char read_value(size_t index) {
    if (index < public_size) {
        unsigned char value = public_data[index];
        return probe[value * 4096];
    }
    return 0;
}

Tahminci, koşulun genellikle doğru olduğuna alıştırılmışsa sınır dışı bir index geldiğinde gövdeyi geçici olarak çalıştırabilir. Mimari sonuç daha sonra silinse de value tarafından seçilen probe satırı önbellekte kalabilir. Saldırgan 256 olası satırın erişim sürelerini karşılaştırarak baytı arar.

Meltdown ve Spectre aynı şey mi?

Meltdown, işlemcinin yetkisiz bellek okumasını hata üretmeden önce geçici olarak ilerletebilmesinden yararlanır. İşletim sistemi sonunda erişimi reddeder; fakat sır önbelleğe kodlanmış olabilir.

Spectre ise kurbanın yasal kodunu yanlış tahminlerle kandırır. Sınır kontrolü bulunsa bile işlemci geçici olarak yanlış yola sokulur. Bu nedenle Spectre tek bir donanım hatasından çok, optimizasyon ile güvenlik modeli arasındaki temel bir çatışmadır.

Savunma neden zor?

Savunmalar arasında KPTI ile çekirdek sayfa tablolarını ayırmak, hassas noktalara spekülasyon bariyerleri eklemek, mikro kod güncellemeleri ve tarayıcılarda zamanlayıcı hassasiyetini azaltmak bulunur. Ancak her bariyer işlemciye “Burada tahmin etme, bekle” dediği için performans maliyeti doğurabilir.

Meltdown ve Spectre’nin büyük dersi şudur: Bir işlem mimari olarak gerçekleşmemiş sayılsa bile fiziksel sistemde iz bırakabilir. Güvenlik yalnızca programın ürettiği sonuçları değil; önbellekleri, tahmincileri, zamanlamayı ve geçici yürütmenin bütün gölgelerini hesaba katmalıdır.

``

Fikir nereden çıktı?

“Öğrenmeyi öğrenme” düşüncesi yapay zekâdan daha eskidir. Psikoloji, insanların önceki deneyimlerinden yararlanarak yeni becerileri daha hızlı kazandığını uzun süredir inceliyordu. Makine öğrenmesinde ise erken dönem çalışmalar, algoritmaların kendi öğrenme kurallarını ayarlayıp ayarlayamayacağı sorusuna odaklandı.

1990’larda sinir ağlarının ağırlık güncellemelerini başka ağlarla yönetme fikri belirginleşti. 2000’lerde çoklu görev öğrenmesi ve aktarım öğrenmesi güçlü temeller sağladı. 2010’ların ortasında derin öğrenme, büyük veri kümeleri ve GPU’larla birleşince meta-learning uygulanabilir hâle geldi. 2016 tarihli Matching Networks ve 2017’de yayımlanan MAML, alanın en etkili dönüm noktaları arasında yer aldı.

Görevler üzerinden öğrenmek

Normal eğitimde veri noktaları örneklenir. Meta-learning eğitiminde ise görevler örneklenir. Her görev genellikle iki parçaya ayrılır:

• Destek kümesi: Modelin göreve uyum sağladığı az sayıdaki örnek.
• Sorgu kümesi: Uyumun gerçekten işe yarayıp yaramadığını ölçen örnekler.

Bir görev $T_i$ için destek kaybı $L_{S_i}$ olsun. Modelin başlangıç parametreleri $θ$ ise tek adımlık uyarlama şöyle yazılabilir:

Burada $α$ iç döngünün öğrenme oranıdır. Meta-model, uyarlanmış parametrelerin sorgu kümelerindeki toplam hatasını azaltmaya çalışır:

İşin sihri burada yatar: Sistem yalnızca doğru cevabı değil, birkaç gradyan adımından sonra iyi sonuç verecek bir başlangıç noktası öğrenir. MAML’ın modelden bağımsız sayılmasının nedeni de bu fikrin sınıflandırma, regresyon veya pekiştirmeli öğrenme gibi farklı alanlara uygulanabilmesidir.

Üç ana meta-learning ailesi

Metrik tabanlı yöntemlerde her sınıfın prototipi hesaplanabilir. $k$ sınıfına ait destek temsillerinin ortalaması:

Yeni örnek, temsili hangi $c_k$ noktasına daha yakınsa o sınıfa atanır. Bir bakıma model, “Bu fotoğraf hangi aile albümüne daha çok benziyor?” diye sorar.

MAML mantığının küçük bir kod karşılığı

Aşağıdaki PyTorch taslağı, tek görev için iç güncelleme yapar ve sorgu kaybını hesaplar. create_graph=True, dış döngünün iç güncelleme üzerinden türev alabilmesini sağlar:

import torch
from torch.func import functional_call

support_logits = model(x_support)
support_loss = loss_fn(support_logits, y_support)

params = dict(model.named_parameters())
grads = torch.autograd.grad(
    support_loss,
    params.values(),
    create_graph=True
)

fast_params = {
    name: param - inner_lr * grad
    for (name, param), grad in zip(params.items(), grads)
}

query_logits = functional_call(model, fast_params, (x_query,))
outer_loss = loss_fn(query_logits, y_query)

optimizer.zero_grad()
outer_loss.backward()
optimizer.step()

Gerçek uygulamada bu işlem birçok görev için tekrarlanır ve sorgu kayıpları ortalanır. Hesaplama maliyeti özellikle ikinci dereceden türevler nedeniyle yükselebilir; First-Order MAML ve Reptile gibi yöntemler bu yükü azaltmayı hedefler.

Neden önemli?

Meta-learning; nadir hastalıkların sınıflandırılması, yeni robot hareketleri, kişiselleştirilmiş öneriler ve az kaynaklı diller gibi verinin pahalı olduğu alanlarda değerlidir. Yine de görev dağılımı kötü seçilirse model yeni koşullara uyum sağlayamaz. Kısacası öğrenmeyi öğrenen bir sistem de öğretmeninin hazırladığı müfredat kadar iyidir. Meta-learning’in büyük vaadi, her şeyi bilen modeller değil; bilmediği bir şeyle karşılaştığında ne yapacağını daha çabuk anlayan modeller üretmesidir.

``

Temel fark: Uyku mu, aktif bekleme mi?

Bir mutex alınamıyorsa bekleyen iş parçacığı çoğunlukla işletim sistemi tarafından uyutulur. Böylece işlemci başka işler çalıştırabilir. Ancak uyutma ve yeniden uyandırma; sistem çağrıları, zamanlayıcı müdahalesi ve bağlam değişimi gibi maliyetler doğurur.

Bir spinlock ise iş parçacığını uyutmaz. İş parçacığı kilidi tekrar tekrar kontrol ederek işlemci üzerinde aktif kalır. Kilit birkaç nanosaniye sonra açılacaksa bu yaklaşım oldukça hızlıdır. Bekleme uzarsa işlemci zamanı ve enerji boşa harcanır.

Maliyetin matematiği

Spinlock seçiminin mantıklı olması için bekleme maliyetinin uyutma maliyetinden küçük olması beklenir. Basitleştirilmiş karar koşulu şöyledir:

Kilit ortalama $T_k$ süre tutuluyor ve kilidi dolu bulma olasılığı $P_c$ ise spinlock için yaklaşık bekleme maliyeti $P_c \times T_k$ olarak düşünülebilir. Mutex tarafında ise bağlam değiştirme maliyeti devreye girer. Modern sistemlerde bu değerler sabit değildir; çekirdek sayısı, önbellek mimarisi ve sistem yükü sonucu değiştirir.

Spinlock yalnızca döngü maliyeti de değildir. Kilit değişkeninin farklı çekirdeklerin önbellekleri arasında taşınması cache coherence trafiği oluşturur. Çok sayıda çekirdek aynı bellek satırını izliyorsa küçücük bir atomik değişken, sistemin en popüler dedikodu konusu hâline gelebilir.

C++ ile iki yaklaşım

Aşağıdaki basit spinlock, atomic_flag kullanarak kilidi atomik biçimde almaya çalışır. yield, işletim sistemine başka bir iş parçacığını çalıştırabileceğini söyler; fakat kilidi gerçek anlamda uyuyan bir mutex hâline getirmez.

#include <atomic>
#include <thread>

class SpinLock {
    std::atomic_flag locked = ATOMIC_FLAG_INIT;

public:
    void lock() {
        while (locked.test_and_set(std::memory_order_acquire)) {
            std::this_thread::yield();
        }
    }

    void unlock() {
        locked.clear(std::memory_order_release);
    }
};

Aynı kritik bölüm standart mutex ile daha güvenli ve okunaklı biçimde korunabilir:

#include <mutex>

std::mutex mutex;
int counter = 0;

void increment() {
    std::lock_guard<std::mutex> guard(mutex);
    ++counter; // Paylaşılan veriyi güvenle günceller.
}

std::lock_guard, fonksiyondan istisnayla çıkılsa bile mutex kilidini otomatik bırakır. Üretim kodunda bu RAII yaklaşımı, elle lock ve unlock çağırmaktan daha güvenlidir.

Hangisini ne zaman seçmeli?

Kritik bölüm birkaç atomik işlem kadar kısaysa, çekirdek sayısı yeterliyse ve çakışma düşükse spinlock avantaj sağlayabilir. İşlem bloklayıcı G/Ç yapıyor, bellek ayırıyor veya süresi öngörülemeyen başka kodlar çağırıyorsa mutex daha doğru seçimdir. Spinlock tutulurken uyumak ise performans felaketinin davetiyesidir.

Modern mutex uygulamalarının önce kısa süre dönüp sonra uyuyan adaptif stratejiler kullanabildiğini de unutmayın. Dolayısıyla teorik tahmin tek başına yeterli değildir. Gerçek iş yükünü benchmark ve profiler ile ölçün. En hızlı kilit bazen spinlock, bazen mutex; çoğu zamansa paylaşılan veriyi azaltarak hiç ihtiyaç duymadığınız kilittir.