Das Problem der meisten Kernelentwickler ist einfach, dass es immer wieder Variablen gibt, die man gerne mal einsehen würde, die aber im Produktivbetrieb nie gebraucht werden. Bis jetzt wird das sehr oft über #ifdef DEBUG_IN_MY_MODULE_NOT_EVERYWHERE oder sonstiges geregelt, wenn debugfs sich durchsetzt, dann entfällt das, da die Entwickler anstelle der #ifdefs ein debugfs_register() nutzen.

Vorteile von debugfs:
Öffentliche Schnittstellen bleiben in procfs und/oder sysfs
Variablen, die man nutzen kann um Treiber zu debugen ohne gleich das ganze Modul in den Debugmodus zu versetzen nach debugfs.
Vereinheitlichtes DEBUG System

Nachteile:
Noch ein FS im Kernel, das ähnliche Funktionen erfüllt, wie bereits erhaltene. Aber man kann das FS ja komplett aus dem Kernel nehmen.

Als Beispiel für Nutzer fallen mir libata und einige SCSI Treiber ein. Das exportieren der Register nach proc ist beim besten willen keine gute Idee (proc sollte stabil sein von den Dateien her). Sysfs kommt nicht in Frage, weil für jedes Register eine Datei zu registrieren wäre Overkill. Im Debugfs wäre es besser aufgehoben, läuft das System, so wird debugfs einfach nicht gemountet, hat man Probleme, dann mountet man es und kann dort auf diese Informationen zugreifen. Selbst falsch gesetzte Berechtigungen könnten das System nicht beeinträchtigen, debugfs wird einfach keine Zugriffe von UID!=0 zulassen, damit darf nur root lesen/schreiben. Ich find die Idee gut und hoffe es setzt sich durch.

Gruß

Devlin