ich bin kein Kernelentwickler, aber ich habe schon das eine oder andere Mal in der Arbeit geflucht, als ich Timeouts vom TCP/IP Stack ändern wollte. Hoffentlich geht das jetzt, so wie es unter HP und Solaris mit dem ndd Kommando schon lange geht.
Und auch das Ändern von Kernelvariablen zur Laufzeit scheint dann nicht mehr unmöglich zu sein, so dass man ohne Reboot bestimmte Grenzwerte und Puffer anpassen kann. Es scheint so, als ob Linux jetzt wirklich erwachsen wird und bei den großen Unices mitspielen will.
klar kenne ich /proc - ich hoffe halt nur, dass ein paar mehr Variablen durch das debugfs zugänglich werden. Da habe ich mich wohl unklar ausgedrückt. Wie sieht es denn zum Beispiel mit TCP_TIME_WAIT_TIMEOUT aus. Das blöde Ding ist fest im Quelltext definiert und ich hatte keine Möglichkeit den Wert runterzusetzen, damit die abgebrochenen Verbindungen schneller abgebaut werden. Und Kernel rekompilieren kam an der Stelle nicht in Frage...
Von BufferOverflow am Mo, 13. Dezember 2004 um 11:41 #
Wenn man den Dieter Nuhr aus der Kiste kramt, um anderen anzudeuten, sie haetten keine Ahnung, sollte man bedenken, dass man selber zu den Leuten ohne Ahnung gehoert:
Den Spruch "Wenn man keine Ahnung hat, einfach mal Fresse halten" hat Dieter Nuhr naemlich nur stumpf bei Alfred Tetzlaff geklaut, der in den 70er Jahren den Spruch "Wenn man keine Ahnung hat, sollte man bescheiden die Schnauze halten" gebracht hat....
Soweit also zu dem "Totschlagargument" Dieter Nuhr...
Ist ja eigentlich ne ganz gute Idee, einfachen Zugriff auf Kernelvariablen zu ermöglichen. Aber worin unterscheidet sich das denn nun von /proc ? Vielleicht ist es ja auch besser, mal die Beschränkungen von Bestehenden Lösungen zu beheben, statt gleich was neues zu bauen, das aber eigentlich genau das gleiche macht. "procfs", "sysfs", jetzt noch "debugfs" erfüllen nunmal die gleiche Aufgabe. Da könnte man sich auch eine einheitlichere Lösung vorstellen.
Wenn Du schon alles besser weist, dann versuche lieber mal, eine sinnvolle Erklärung zu schreiben. Dieses Forum soll schließlich auch dazu dienen, zu diskutieren. Wenn Du dazu nicht konstruktiv beitragen willst, oder kannst, dann poste doch einfach nicht!
Von BufferOverflow am Mo, 13. Dezember 2004 um 12:58 #
Wieso weiss ich alles besser? Lies einfach mal den Bericht und dann haettest Du Dir Deine Frage sparen koennen und ich mir meine Antwort und Du Dir Dein Gezicke auf meine Antwort. Ist das zuviel verlangt?
In Deinem Posting habe ich leider keine Antwort finden können! Davon abgesehen zwingt Dich natürlich auch niemand, hier was zu schreiben.
Um mal den Autor dieses Dateisystems aus den Original-Artikel zu zitieren: "> In principle, it is the same as /proc, just with the explicit > information that binary compatibility will never be a goal, right?
Yes, that is correct."
Also ist diese Frage doch durchaus diskussionswürdig.
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.
ich bin kein Kernelentwickler, aber ich habe schon das eine oder andere Mal in der Arbeit geflucht, als ich Timeouts vom TCP/IP Stack ändern wollte. Hoffentlich geht das jetzt, so wie es unter HP und Solaris mit dem ndd Kommando schon lange geht.
Und auch das Ändern von Kernelvariablen zur Laufzeit scheint dann nicht mehr unmöglich zu sein, so dass man ohne Reboot bestimmte Grenzwerte und Puffer anpassen kann. Es scheint so, als ob Linux jetzt wirklich erwachsen wird und bei den großen Unices mitspielen will.
Johanes
Änderung von Kernelvariablen zur Laufzeit wird dann möglich?
Schon einmal einen Blick ins /proc geworfen? Du kennst sysctl?
Bitte Dieter Nuhr beachten!
klar kenne ich /proc - ich hoffe halt nur, dass ein paar mehr Variablen durch das debugfs zugänglich werden. Da habe ich mich wohl unklar ausgedrückt. Wie sieht es denn zum Beispiel mit TCP_TIME_WAIT_TIMEOUT aus. Das blöde Ding ist fest im Quelltext definiert und ich hatte keine Möglichkeit den Wert runterzusetzen, damit die abgebrochenen Verbindungen schneller abgebaut werden. Und Kernel rekompilieren kam an der Stelle nicht in Frage...
Gruß
Johanes
Den Spruch "Wenn man keine Ahnung hat, einfach mal Fresse halten" hat Dieter Nuhr naemlich nur stumpf bei Alfred Tetzlaff geklaut, der in den 70er Jahren den Spruch "Wenn man keine Ahnung hat, sollte man bescheiden die Schnauze halten" gebracht hat....
Soweit also zu dem "Totschlagargument" Dieter Nuhr...
mfG
Vielleicht ist es ja auch besser, mal die Beschränkungen von Bestehenden Lösungen zu beheben, statt gleich was neues zu bauen, das aber eigentlich genau das gleiche macht. "procfs", "sysfs", jetzt noch "debugfs" erfüllen nunmal die gleiche Aufgabe. Da könnte man sich auch eine einheitlichere Lösung vorstellen.
[ ] Du hast den Text komplett gelesen
[X] Du hast nur die Ueberschrift und die ersten beiden Absaetze gelesen
mfG
Lies einfach mal den Bericht und dann haettest Du Dir Deine Frage sparen koennen und ich mir meine Antwort und Du Dir Dein Gezicke auf meine Antwort.
Ist das zuviel verlangt?
mfG
Grüßle
wing
Um mal den Autor dieses Dateisystems aus den Original-Artikel zu zitieren:
"> In principle, it is the same as /proc, just with the explicit
> information that binary compatibility will never be a goal, right?
Yes, that is correct."
Also ist diese Frage doch durchaus diskussionswürdig.
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