Arsitektur Out-of-Tree Driver: Trade-off DKMS vs Upstream

Mengembangkan device driver untuk Linux memaksa tim engineering memilih satu dari dua jalur: menggabungkan kode ke repositori kernel utama (upstream) atau mengelolanya secara terpisah sebagai out-of-tree (OOT) module melalui DKMS (Dynamic Kernel Module Support). Pilihan ini bukan sekadar preferensi teknis, melainkan komitmen arsitektural yang berdampak langsung pada siklus rilis, stabilitas produksi, dan beban pemeliharaan jangka panjang.

Stabilitas kABI dan Prinsip Desain Kernel Linux

Linux tidak mempertahankan antarmuka biner kernel (kABI) yang stabil antar rilis. Kebijakan resmi kernel menyatakan bahwa antarmuka internal bersifat dinamis dan dapat berubah kapan saja jika arsitektur yang lebih baik ditemukan. Akibatnya, modul kernel yang dikompilasi untuk kernel versi 6.6 tidak dijamin dapat dimuat atau berjalan normal pada versi 6.7.

Pendekatan ini menguntungkan repositori upstream karena pengembang inti bebas membersihkan kode lama dan memperbaiki bug tanpa terikat kompatibilitas mundur. Namun, bagi pengembang driver out-of-tree, ketiadaan kABI stabil menciptakan friksi berkelanjutan: setiap update kernel minor pada sistem operasi target berpotensi merusak kompatibilitas fungsi (misalnya perubahan signature fungsi API, perubahan struct data internal, atau relokasi header).

Friksi Maintenance dan Tekanan Regulasi

Menyerahkan kode ke upstream (upstream submission) membutuhkan waktu berbulan-bulan untuk review kode, penyesuaian gaya penulisan, dan penyelarasan filosofi subsistem dengan para kernel maintainer. Hambatan ini kian kompleks saat bersinggungan dengan regulasi korporasi atau geopolitik.

Diskusi seputar "spoiling kernel with sanctioned code" menyoroti celah kepatuhan: regulasi sanksi perdagangan dan pembatasan transfer teknologi dapat membatasi entitas tertentu untuk berkolaborasi langsung dalam mailing list kernel Linux upstream. Saat kepatuhan hukum menghalangi kontribusi publik, vendor terpaksa memilih arsitektur out-of-tree atau vendor-specific forks. Memilih out-of-tree menyelesaikan hambatan legal seketika, namun mengalihkan seluruh beban porting dan validasi kABI ke pundak tim internal pengembang driver.

Perbandingan Arsitektur: DKMS, Vendor Patching, dan Upstream

Implementasi DKMS yang Tangguh

Jika DKMS dipilih karena batas regulasi atau kebutuhan siklus rilis yang cepat, modul harus dirancang tahan banting terhadap perubahan API. Gunakan macro pemeriksaan versi kernel di kode sumber driver C:

#include <linux/version.h>

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 0)
    /* Penyesuaian API baru */
    class_create(THIS_MODULE, DEVICE_NAME);
#else
    /* Fallback API lama */
    class_create(DEVICE_NAME);
#endif

Di tingkat deployment, berkas dkms.conf minimal harus membatasi eksekusi paralel dan mendeklarasikan instruksi instalasi yang deterministik:

PACKAGE_NAME="my_custom_driver"
PACKAGE_VERSION="1.2.0"
CLEAN="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build clean"
MAKE[0]="make -C ${kernel_source_dir} M=${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build modules"
BUILT_MODULE_NAME[0]="my_custom_driver"
DEST_MODULE_LOCATION[0]="/updates/dkms/"
AUTOINSTALL="yes"

Biaya Operasional dan Siklus Hidup Produksi

Mengadopsi DKMS di infrastruktur produksi skala besar menuntut pipeline CI/CD yang agresif. Anda harus menguji kompilasi modul terhadap kernel di repositori staging/testing setiap distribusi Linux sebelum update kernel tersebut mendarat di node produksi. Masalah umum meliputi:

• Build Failure saat Boot: Update otomatis distro memicu kompilasi DKMS pada environment tanpa memory cukup atau tanpa paket kernel-headers yang cocok, menyebabkan kernel panik atau peripheral gagal beroperasi.
• Secure Boot Block: Mesin produksi menolak memuat driver OOT jika proses sign dengan MOK lokal tidak diotomasi dengan benar.
• Technical Debt: Menjaga kode kompatibel dengan Linux 4.19 hingga 6.x via ratusan #ifdef LINUX_VERSION_CODE meningkatkan kompleksitas kode secara eksponensial.

Alur Pengambilan Keputusan Arsitektur

Evaluasi opsi modul kernel dengan panduan berikut:

1. Apakah hardware/driver ditargetkan untuk pasar umum dan bebas restriksi legal/lisensi?
   Pilih Upstream. Biaya integrasi di awal terbayar penuh oleh nihilnya beban maintain kABI di kemudian hari.
2. Apakah Anda mengontrol seluruh environment mesin (misalnya embedded Linux atau appliance khusus)?
   Pilih Vendor Patching. Bekukan versi kernel untuk meminimalkan moving target kABI.
3. Apakah perangkat harus mendukung berbagai distro umum (Ubuntu, RHEL, Debian) tanpa izin lisensi upstream?
   Pilih DKMS. Bangun matriks uji CI/CD otomatis terhadap repositori distro untuk mendeteksi breaking API sebelum klien Anda memperbarui sistem mereka.