GKI için çekirdek kodu geliştirme

Genel Çekirdek Görüntüsü (GKI), yayın öncesi Linux çekirdeğiyle yakından uyum sağlayarak çekirdek parçalanmasını azaltır. Ancak bazı yamaların yayın öncesi kabul edilememesinin geçerli nedenleri vardır ve uyulması gereken ürün programları vardır. Bu nedenle, bazı yamalar GKI'nın derlendiği Android Ortak Çekirdeği (ACK) kaynaklarında korunur.

Geliştiriciler, kod değişikliklerini ilk tercih olarak Linux Kernel Mailing List'i (LKML) kullanarak ana akışa göndermeli ve yalnızca ana akış için geçerli bir neden olmadığında ACKandroid-mainline şubesine göndermelidir. Geçerli neden örnekleri ve bunların nasıl ele alınacağına ilişkin örnekler aşağıda verilmiştir.

  • Yama LKML'ye gönderildi ancak ürün sürümü için zamanında kabul edilmedi. Bu yamayı işlemek için:

    • Yama'nın LKML'ye gönderildiğine ve Yama için yorum alındığına dair kanıt veya Yama'nın yayın öncesi gönderilme zamanının tahmini bilgisini sağlayın.
    • Yamayı ACK'ye uygulamak, üretim için onaylatmak ve nihai yukarı akış sürümü ACK'ye birleştirildiğinde ACK'den çıkarmak için bir eylem planı belirleyin.

  • Yama, bir tedarikçi modülü için EXPORT_SYMBOLS_GPL()'ü tanımlar ancak bu simgeyi kullanan ağaç içi modül olmadığından yayın öncesine gönderilemez. Bu yamayı işlemek için modülünüzün neden yayın öncesi gönderilemediğine ve bu isteği yapmadan önce değerlendirdiğiniz alternatiflere dair ayrıntılı bilgi verin.

  • Yama, yayın öncesi için yeterince genel değildir ve ürün sürümü yayınlanmadan önce yeniden yapılandırmaya zaman yoktur. Bu yamayı işlemek için, yeniden yapılandırılmış bir yamanın yayına gönderileceği tahmini zamanı belirtin (yeniden yapılandırılmış bir yamanın inceleme için yayına gönderilme planı olmadan ACK'de kabul edilmez).

  • Yama, aşağıdaki nedenlerden dolayı yayın öncesi tarafından kabul edilemez: <insert reason here>. Bu yamayı işlemek için Android çekirdek ekibiyle iletişime geçin ve incelemeye gönderilip yayın öncesi kabul edilebilmesi için yamayı yeniden yapılandırmaya yönelik seçenekler konusunda bizimle birlikte çalışın.

Bunun gibi birçok olası gerekçe vardır. Hatanızı veya düzeltmenizi gönderirken geçerli bir gerekçe ekleyin ve bazı iterasyonlar ve tartışmalar bekleyin. Herkesin üretime yönelik çalışma yapmayı öğrendiği halde ürün planlamalarını buna göre esnetemediğini, özellikle de GKI'nın ilk aşamalarında bazı yamalar içerdiğinin farkındayız.

Yama gereksinimleri

Yamalar, yukarı akış veya ACK'ye gönderilmelerinden bağımsız olarak Linux kaynak ağacında açıklanan Linux çekirdek kodlama standartlarına uygun olmalıdır. scripts/checkpatch.pl komut dosyası, Gerrit ön gönderme testinin bir parçası olarak çalıştırılır. Bu nedenle, başarılı olduğundan emin olmak için komutu önceden çalıştırın. checkpatch komut dosyasını, göndermeden önce testle aynı yapılandırmayla çalıştırmak için //build/kernel/static_analysis:checkpatch_presubmit kullanın. Ayrıntılar için build/kernel/kleaf/docs/checkpatch.md dosyasını inceleyin.

ACK yamaları

ACK'ya gönderilen yamalar, Linux çekirdek kodlama standartlarına ve katkı yönergelerine uygun olmalıdır. Commit mesajına bir Change-Id etiketi eklemeniz gerekir. Düzeltmeyi birden fazla şubeye (ör. android-mainline ve android12-5.4) gönderirseniz düzeltmenin tüm örnekleri için aynı Change-Id değerini kullanmanız gerekir.

Öncelikle yukarı akış incelemesi için LKML'ye gönderin. Yama:

  • Yukarı akışta kabul edilen bu veri türü, otomatik olarak android-mainline ile birleştirilir.
  • Yukarı akışta kabul edilmedi. Yukarı akıştaki gönderime referans vererek veya LKML'ye gönderilmemesinin nedenini açıklayarak android-mainline adresine gönderin.

Bir yama, yayın öncesi veya android-mainline'te kabul edildikten sonra, uygun LTS tabanlı ACK'ye (ör. Android'e özgü kodu düzelten yamalar için android12-5.4 ve android11-5.4) geri aktarılabilir. android-mainline'e gönderim yapmak, yeni yayın adayı üst akış sürümleriyle test yapmanızı sağlar ve yamanın bir sonraki LTS tabanlı ACK'de yer alacağını garanti eder. İstisnalar arasında, yayın öncesi bir yamanın android12-5.4'e geri bağlandığı durumlar (yama muhtemelen android-mainline'te zaten bulunduğu için) yer alır.

Yukarı akış yamaları

Katkı yönergelerinde belirtildiği gibi, ACK çekirdeklerine yönelik yayın öncesi yamalar aşağıdaki gruplara ayrılır (kabul edilme olasılığına göre sıralanmıştır).

  • UPSTREAM: - Makul bir kullanım alanı varsa "android-mainline"den seçilen yamalar ACK'ye kabul edilebilir.
  • BACKPORT: - Makul bir kullanım alanı varsa, üst taraftan gelen ve dikkatlice seçilmemiş, değiştirilmesi gereken yamalar da kabul edilebilir.
  • FROMGIT: - Linux ana hatlarına gönderilmek üzere hazırlanırken bir bakım dalından özenle seçilen yamalar, yaklaşan bir son tarih varsa kabul edilebilir. Bu değişiklikler hem içerik hem de planlama açısından gerekçelendirilmelidir.
  • FROMLIST: - LKML'ye gönderilmiş ancak henüz bir bakım dalına kabul edilmemiş yamalar, gerekçesi üst Linux'a eklenip eklenmeyeceğine bakılmaksızın yamanın kabul edileceği kadar ikna edici olmadığı sürece kabul edilmeyebilir (bu durumun gerçekleşmeyeceğini varsayıyoruz). Android çekirdek ekibiyle görüşmeyi kolaylaştırmak için FROMLIST yamalarıyla ilişkili bir sorun olması gerekir.

Android'e özel yamalar

Gerekli değişiklikleri ana akışa ekleyemiyorsanız ağaç dışı yamaları doğrudan ACK'ye göndermeyi deneyebilirsiniz. Ağ dışındaki yamaları göndermek için BT'de, yamayı ve yamanın yukarı akışa neden gönderilemediğini belirten bir sorun oluşturmanız gerekir (örnek için önceki listeye bakın). Ancak kodun ana akışa gönderilemediği bazı durumlar vardır. Bu destek kayıtları aşağıdaki şekilde ele alınır ve Android'e özel yamalar için katkı yönergelerine uymalı, konu kısmında ANDROID: ön ekiyle etiketlenmelidir.

gki_defconfig değişiklikleri

CONFIG mimariye özgü olmadığı sürece CONFIG'deki tüm gki_defconfig değişiklikleri hem arm64 hem de x86 sürümlerine uygulanmalıdır. CONFIG ayarlarında değişiklik isteğinde bulunmak için BT bölümünde değişiklik hakkında görüşmek üzere bir sorun oluşturun. CONFIG Dondurulduktan sonra Kernel Module Interface (KMI) üzerinde yapılan tüm değişiklikler reddedilir. İş ortaklarının tek bir yapılandırma için çakışan ayarlar istemesi durumunda, çakışmaları ilgili hatalar üzerinde tartışarak çözeriz.

Yukarı akışta olmayan kod

Android'e özgü kodda yapılan değişiklikler yayına gönderilemez. Örneğin, bağlayıcı sürücüsü yayın öncesi olarak yönetilse bile Android'e özgü oldukları için bağlayıcı sürücüsünün öncelik devralma özelliklerinde yapılan değişiklikler yayın öncesi olarak gönderilemez. Hatanızda ve yamasında, kodun neden yukarı akışa gönderilemediğini açıkça belirtin. ACK'de tutulan ağaç dışı kod miktarını en aza indirmek için mümkünse yamaları, üretime gönderilebilecek ve yukarı akışla gönderilemeyecek Android'e özgü parçalara ayırın.

Bu kategoride yer alan diğer değişiklikler; KMI temsil dosyalarında, KMI simge listelerinde, gki_defconfig'de, derleme komut dosyalarında veya yapılandırmada ya da yukarı akışta bulunmayan diğer komut dosyalarında yapılan güncellemelerdir.

Ağ dışındaki modüller

Upstream Linux, ağaç dışı modüllerin oluşturulmasına yönelik desteği aktif olarak caydırıyor. Linux bakım ekiplerinin çekirdek içi kaynak veya ikili uyumluluk hakkında garanti vermemesi ve ağaçta bulunmayan kodu desteklemek istememesi nedeniyle bu makul bir tutumdur. Ancak GKI, tedarikçi modülleri için ABI garantileri verir. Bu sayede KMI arayüzlerinin, bir çekirdeğin desteklenen ömrü boyunca kararlı olmasını sağlar. Bu nedenle, ACK için kabul edilebilir ancak yayın için kabul edilemez tedarikçi modüllerini desteklemek üzere bir değişiklik sınıfı vardır.

Örneğin, dışa aktarmayı kullanan modüllerin kaynak ağaçta olmadığı bir yere EXPORT_SYMBOL_GPL() makroları ekleyen bir yamayı düşünün. EXPORT_SYMBOL_GPL()'ü yayın öncesi isteğinde bulunmaya ve yeni dışa aktarılan simgeyi kullanan bir modül sağlamaya çalışmanız gerekir. Ancak modülün yayın öncesi gönderilmemesinin geçerli bir nedeni varsa bunun yerine yamayı ACK'ye gönderebilirsiniz. Modülün neden yayına alınamadığını sorununuza eklemeniz gerekir. (GPL olmayan EXPORT_SYMBOL() varyantını istemeyin.)

Gizli yapılandırmalar

Bazı ağaç içi modüller, gki_defconfig içinde belirtilemeyen gizli yapılandırmaları otomatik olarak seçer. Örneğin, CONFIG_SND_SOC_SOF=y yapılandırıldığında CONFIG_SND_SOC_TOPOLOGY otomatik olarak seçilir. GKI, ağaç dışı modül derlemelerini sağlamak için gizli yapılandırmaları etkinleştiren bir mekanizmaya sahiptir.

Gizli bir yapılandırmayı etkinleştirmek için init/Kconfig.gki'a bir select ifadesi ekleyin. Böylece, gki_defconfig'da etkinleştirilen CONFIG_GKI_HACKS_TO_FIX çekirdek yapılandırmasına göre otomatik olarak seçilir. Bu mekanizmayı yalnızca gizli yapılandırmalar için kullanın. Yapılandırma gizli değilse gki_defconfig içinde açıkça veya bağımlılık olarak belirtilmelidir.

Yüklenebilir denetleyiciler

Yüklenebilir denetleyicileri destekleyen çekirdek çerçeveleri (cpufreq gibi) için varsayılan denetleyiciyi (cpufreq'ın schedutil denetleyicisi gibi) geçersiz kılabilirsiniz. Yüklenebilir denetleyicileri veya sürücüleri desteklemeyen ancak yine de tedarikçiye özel bir uygulama gerektiren çerçeveler (termal çerçeve gibi) için BT'de bir sorun oluşturun ve Android çekirdek ekibine danışın.

Gerekli desteği eklemek için sizinle ve üst yöndeki koruyucularla birlikte çalışacağız.

Tedarikçi firma kancaları

Geçmiş sürümlerde, tedarikçi firmaya özgü değişiklikleri doğrudan temel çekirdeğe ekleyebilirsiniz. Ürüne özgü kod modüllere uygulanmak zorunda olduğundan ve yayın öncesi çekirdek çekirdeklerinde veya ACK'de kabul edilmediğinden bu, GKI 2.0 ile mümkün değildir. GKI, iş ortaklarının temel çekirdek koduna en az düzeyde etki edecek şekilde yararlandığı katma değerli özellikleri etkinleştirmek için modüllerin temel çekirdek kodundan çağrılmasına olanak tanıyan tedarikçi bağlantı noktalarını kabul eder. Ayrıca, bu özellikleri uygulamak için tedarikçiye özgü verileri depolamak üzere kullanılabilen tedarikçi veri alanlarıyla temel veri yapıları doldurulabilir.

Tedarikçi firma kancaları, tedarikçi firma modüllerinin ekleyebildiği izleme noktalarına (izleme etkinliklerine değil) dayalı iki varyantta (normal ve kısıtlanmış) bulunur. Örneğin, tedarikçi firmalar görev çıkışında muhasebe yapmak için yeni bir sched_exit() işlevi eklemek yerine do_exit()'a bir kanca ekleyerek tedarikçi firma modülünün işleme ekleyebilmesini sağlayabilir. Örnek bir uygulama aşağıdaki satıcı kancalarını içerir.

  • Normal tedarikçi bağlantı noktaları, DECLARE_HOOK() adını kullanarak trace_name adlı bir izleme noktası işlevi oluşturur. Bu işlevde name, izlemenin benzersiz tanımlayıcısıdır. Normal tedarikçi firma kanca adları android_vh ile başlar. Bu nedenle, sched_exit() kancasının adı android_vh_sched_exit olur.
  • CPU çevrimdışı olsa veya atom olmayan bir bağlam gerektirse bile ekli işlevin çağrılması gereken planlayıcı kancaları gibi durumlarda kısıtlanmış tedarikçi kancaları gereklidir. Kısıtlanmış tedarikçi kancaları ayrılamaz. Bu nedenle, kısıtlanmış bir kancaya bağlanan modüller hiçbir zaman kaldırılamaz. Kısıtlanmış tedarikçi kanca adları android_rvh ile başlar.

Tedarikçi kancası eklemek için BT'de bir sorun dosyası oluşturun ve yamalar gönderin (Android'e özgü tüm yamalar için olduğu gibi, bir sorun mevcut olmalı ve gerekçe sunmanız gerekir). Tedarikçi kancaları yalnızca ACK'de desteklenir. Bu nedenle, bu yamaları Linux'a göndermeyin.

Yapılara tedarikçi alanları ekleme

ANDROID_VENDOR_DATA() makrolarını kullanarak android_vendor_data alanları ekleyerek tedarikçi firma verilerini temel veri yapılarıyla ilişkilendirebilirsiniz. Örneğin, katma değerli özellikleri desteklemek için aşağıdaki kod örneğinde gösterildiği gibi alanlara yapı ekleyin.

Tedarikçi firmaların ihtiyaç duyduğu alanlar ile OEM'lerin ihtiyaç duyduğu alanlar arasında olası çakışmaları önlemek için OEM'ler hiçbir zaman ANDROID_VENDOR_DATA() makroları kullanılarak tanımlanan alanları kullanmamalıdır. Bunun yerine OEM'ler, android_oem_data alanlarını bildirmek için ANDROID_OEM_DATA() kullanmalıdır.

#include <linux/android_vendor.h>
...
struct important_kernel_data {
  [all the standard fields];
  /* Create vendor data for use by hook implementations. The
   * size of vendor data is based on vendor input. Vendor data
   * can be defined as single u64 fields like the following that
   * declares a single u64 field named "android_vendor_data1" :
   */
  ANDROID_VENDOR_DATA(1);

  /*
   * ...or an array can be declared. The following is equivalent to
   * u64 android_vendor_data2[20]:
   */
  ANDROID_VENDOR_DATA_ARRAY(2, 20);

  /*
   * SoC vendors must not use fields declared for OEMs and
   * OEMs must not use fields declared for SoC vendors.
   */
  ANDROID_OEM_DATA(1);

  /* no further fields */
}

Tedarikçi firma kancalarını tanımlama

Tedarikçi bağlantı noktalarını DECLARE_HOOK() veya DECLARE_RESTRICTED_HOOK() kullanarak tanımlayıp ardından kodda bir izleme noktası olarak ekleyerek çekirdek koduna ekleyin. Örneğin, mevcut do_exit() çekirdek işlevine trace_android_vh_sched_exit() eklemek için:

#include <trace/hooks/exit.h>
void do_exit(long code)
{
    struct task_struct *tsk = current;
    ...
    trace_android_vh_sched_exit(tsk);
    ...
}

trace_android_vh_sched_exit() işlevi başlangıçta yalnızca bir öğenin eklenip eklenmediğini kontrol eder. Ancak bir tedarikçi modülü register_trace_android_vh_sched_exit() kullanarak bir işleyici kaydederse kayıtlı işlev çağrılır. İşleyici; bekletilen kilitler, RCS durumu ve diğer faktörlerle ilgili bağlamın farkında olmalıdır. Kanca, include/trace/hooks dizininde bir başlık dosyasında tanımlanmalıdır.

Örneğin, aşağıdaki kodda include/trace/hooks/exit.h dosyasında trace_android_vh_sched_exit() için olası bir bildirim verilmiştir.

/* SPDX-License-Identifier: GPL-2.0 */
#undef TRACE_SYSTEM
#define TRACE_SYSTEM sched
#define TRACE_INCLUDE_PATH trace/hooks

#if !defined(_TRACE_HOOK_SCHED_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_HOOK_SCHED_H
#include <trace/hooks/vendor_hooks.h>
/*
 * Following tracepoints are not exported in tracefs and provide a
 * mechanism for vendor modules to hook and extend functionality
 */

struct task_struct;

DECLARE_HOOK(android_vh_sched_exit,
             TP_PROTO(struct task_struct *p),
             TP_ARGS(p));

#endif /* _TRACE_HOOK_SCHED_H */

/* This part must be outside protection */
#include <trace/define_trace.h>

Tedarikçi kancası için gereken arayüzleri örneklemek üzere, kanca beyanını içeren başlık dosyasını drivers/android/vendor_hooks.c'e ekleyin ve simgeleri dışa aktarın. Örneğin, aşağıdaki kod android_vh_sched_exit() kancasının tanımını tamamlar.

#ifndef __GENKSYMS__
/* struct task_struct */
#include <linux/sched.h>
#endif

#define CREATE_TRACE_POINTS
#include <trace/hooks/vendor_hooks.h>
#include <trace/hooks/exit.h>
/*
 * Export tracepoints that act as a bare tracehook (i.e. have no trace
 * event associated with them) to allow external modules to probe
 * them.
 */
EXPORT_TRACEPOINT_SYMBOL_GPL(android_vh_sched_exit);

NOT: ABI kararlılığını garanti etmek için kanca bildiriminde kullanılan veri yapılarının tam olarak tanımlanması gerekir. Aksi takdirde, opak işaretçilerin referansını kaldırmak veya yapıyı boyutlandırılmış bağlamlarda kullanmak güvenli değildir. Bu tür veri yapılarının tam tanımını sağlayan dahil etme özelliği, drivers/android/vendor_hooks.c öğesinin #ifndef __GENKSYMS__ bölümüne eklenmelidir. KMI'yi bozan CRC değişikliklerini önlemek için include/trace/hooks içindeki başlık dosyaları, tür tanımlarının bulunduğu çekirdek başlık dosyasını içermemelidir. Bunun yerine türleri iletin.

Tedarikçi firma kancalarına bağlama

Tedarikçi firma kancalarını kullanmak için tedarikçi firma modülünün kanca için bir işleyici kaydetmesi gerekir (genellikle modül başlatılırken yapılır). Örneğin, aşağıdaki kodda trace_android_vh_sched_exit() için foo.ko modülü işleyicisi gösterilmektedir.

#include <trace/hooks/sched.h>
...
static void foo_sched_exit_handler(void *data, struct task_struct *p)
{
    foo_do_exit_accounting(p);
}
...
static int foo_probe(..)
{
    ...
    rc = register_trace_android_vh_sched_exit(foo_sched_exit_handler, NULL);
    ...
}

Üstbilgi dosyalarındaki tedarikçi firma kancalarını kullanma

Başlık dosyalarından tedarikçi kancaları kullanmak için, bir izleme noktası başlık dosyası bulunamadığını belirten derleme hatalarını önlemek amacıyla tedarikçi kanca başlık dosyasını TRACE_INCLUDE_PATH tanımını kaldıracak şekilde güncellemeniz gerekebilir. Örneğin,

In file included from .../common/init/main.c:111:
In file included from .../common/include/trace/events/initcall.h:74:
.../common/include/trace/define_trace.h:95:10: fatal error: 'trace/hooks/initcall.h' file not found
   95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:90:32: note: expanded from macro 'TRACE_INCLUDE'
   90 | # define TRACE_INCLUDE(system) __TRACE_INCLUDE(system)
      |                                ^~~~~~~~~~~~~~~~~~~~~~~
.../common/include/trace/define_trace.h:87:34: note: expanded from macro '__TRACE_INCLUDE'
   87 | # define __TRACE_INCLUDE(system) __stringify(TRACE_INCLUDE_PATH/system.h)
      |                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:10:27: note: expanded from macro '__stringify'
   10 | #define __stringify(x...)       __stringify_1(x)
      |                                 ^~~~~~~~~~~~~~~~
.../common/include/linux/stringify.h:9:29: note: expanded from macro '__stringify_1'
    9 | #define __stringify_1(x...)     #x
      |                                 ^~
<scratch space>:14:1: note: expanded from here
   14 | "trace/hooks/initcall.h"
      | ^~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

Bu tür bir derleme hatasını düzeltmek için dahil ettiğiniz tedarikçi kancası başlık dosyasına eşdeğer düzeltmeyi uygulayın. Daha fazla bilgi için https://r.android.com/3066703 adresini ziyaret edin.

diff --git a/include/trace/hooks/mm.h b/include/trace/hooks/mm.h
index bc6de7e53d66..039926f7701d 100644
--- a/include/trace/hooks/mm.h
+++ b/include/trace/hooks/mm.h
@@ -2,7 +2,10 @@
 #undef TRACE_SYSTEM
 #define TRACE_SYSTEM mm

+#ifdef CREATE_TRACE_POINTS
 #define TRACE_INCLUDE_PATH trace/hooks
+#define UNDEF_TRACE_INCLUDE_PATH
+#endif

UNDEF_TRACE_INCLUDE_PATH tanımlandığında include/trace/define_trace.h, izleme noktalarını oluşturduktan sonra TRACE_INCLUDE_PATH'nin tanımını kaldırır.

Temel çekirdek özellikleri

Önceki tekniklerden hiçbiri bir modüldeki özelliği uygulamanıza olanak tanımıyorsa özelliği, çekirdek çekirdeğe Android'e özgü bir değişiklik olarak eklemeniz gerekir. Görüşmeyi başlatmak için sorun izleyicide (IT) bir sorun oluşturun.

Kullanıcı uygulama programlama arayüzü (UAPI)

  • UAPI üst dosyaları. Android'e özgü arayüzlerde yapılmadığı sürece UAPI üstbilgi dosyalarında yapılan değişiklikler yayın öncesi aşamada yapılmalıdır. Tedarikçi modülleri ile tedarikçi kullanıcı alanı kodu arasındaki arayüzleri tanımlamak için tedarikçiye özgü başlık dosyalarını kullanın.
  • sysfs düğümleri. GKI çekirdeğine yeni sysfs düğümleri eklemeyin (bu tür eklemeler yalnızca satıcı modüllerinde geçerlidir). SoC ve cihazdan bağımsız kitaplıklar ile Android çerçevesini oluşturan Java kodu tarafından kullanılan sysfs düğümleri yalnızca uyumlu şekillerde değiştirilebilir. Android'e özel sysfs düğümleri değilse bunların yukarı akışla değiştirilmesi gerekir. Tedarikçi firma kullanıcı alanı tarafından kullanılacak tedarikçi firmaya özel sysfs düğümleri oluşturabilirsiniz. Varsayılan olarak, kullanıcı alanı tarafından sysfs düğümlerine erişim SELinux kullanılarak reddedilir. Yetkili tedarikçi yazılımının erişmesine izin vermek için uygun SELinux etiketlerini eklemek tedarikçiye bağlıdır.
  • DebugFS düğümleri. Tedarikçi modülleri, yalnızca hata ayıklama için debugfs içinde düğümler tanımlayabilir (debugfs, cihazın normal çalışması sırasında monte edilmediğinden).