Art der Datenübergabe zwischen Userprog und Kernelmodul.
Martin Freiberg
Hi,
Ich bin gerade dabei fï¿œr eine Bastelei (Zur eigenen ï¿œbung) ein
Kernelmodul zu stricken. Dabei stellt sich mir die Frage der
Datenï¿œbergabe zwischen Modul und Userland Programm.
Im Modul habe ich einen struct den es mit Daten zu fï¿œllen gilt, und
einen weiteren struct von dem ich Daten lesen will.
Auf welchem Weg verwirklicht man hier den Datenaustausch?
Shared memory, ioctl Schnittstelle, oder gar einen Blocktreiber?
Wenn der Datenaustausch schnell gehen soll, ist in dem Fall shared
memory vernï¿œnftig, oder ist ein anderer Weg vorzuziehen?
Und was empfiehlt sich, wenn ich innerhalb des struct nur ein einzelnes
Element schreiben will?
Im Userland eine Kopie halten, dort das Element ï¿œndern und dann die
Daten des struct auf einen rutsch ï¿œbertragen? Oder eine ioctl Routine
erstellen die das erledigt? Oder ï¿œber shared memory, und dort den struct
ablegen?
Gruￜ
Martin
stdUser
On Fri, 02 Oct 2009 00:13:01 +0200, Martin Freiberg wrote:
> Hi,
>
> Ich bin gerade dabei für eine Bastelei (Zur eigenen Übung) ein
> Kernelmodul zu stricken. Dabei stellt sich mir die Frage der
> Datenübergabe zwischen Modul und Userland Programm.
>
> Im Modul habe ich einen struct den es mit Daten zu füllen gilt, und
> einen weiteren struct von dem ich Daten lesen will.
>
> Auf welchem Weg verwirklicht man hier den Datenaustausch? Shared memory,
> ioctl Schnittstelle, oder gar einen Blocktreiber?
>
> Wenn der Datenaustausch schnell gehen soll, ist in dem Fall shared
> memory vernünftig, oder ist ein anderer Weg vorzuziehen?
>
> Und was empfiehlt sich, wenn ich innerhalb des struct nur ein einzelnes
> Element schreiben will?
>
> Im Userland eine Kopie halten, dort das Element ändern und dann die
> Daten des struct auf einen rutsch übertragen? Oder eine ioctl Routine
> erstellen die das erledigt? Oder über shared memory, und dort den struct
> ablegen?
>
>
> Gruß
> Martin
Via Systemcall... indem die "struct *blablubb" im UserSpace mit Daten
befuellt sei und denn diese darob als Argument jenes SysCalls uebergeben
werden kann.
da empfehle ich doch gleich mal ein bisschen lektuere:
Author: Joseph Kong
Title: Designing BSD Rootkits - An introduction to kernel hacking
Contr: No Starch Press
sehr empfehlenswertes Buechlein, da dieses in aeuszerst intuitiv,
uebersichtlicher Weise, dem interessierten Leser, handhabbares Grundwissen
zu vermitteln vermag. Mir hat dieses nette Buechlein hilfreiche Dienste
erwiesen.
MfG
Rainer Weikusat
> Ich bin gerade dabei f锟絩 eine Bastelei (Zur eigenen 锟絙ung) ein
> Kernelmodul zu stricken. Dabei stellt sich mir die Frage der
>
> Im Modul habe ich einen struct den es mit Daten zu f锟絣len gilt, und
> einen weiteren struct von dem ich Daten lesen will.
>
> Auf welchem Weg verwirklicht man hier den Datenaustausch?
> Shared memory, ioctl Schnittstelle, oder gar einen Blocktreiber?
Fuer Linux gilt es mittlerweile (soweit mir das bekannt ist) als comme
il faut, fuer diese Art von Kommunikation 'character device'-Treiber
zu benutzen, vgl epoll, signalfd, timerfd. Die 'traditionelle'
UNIX(*)-Methode dafuer waere ioctl. Ob man open/ read/ write/ close/
(select/ poll ...) fuer den wesentlicheren Punkt des urspruenglichen
Designs erklaert, oder 'Dateien sind vom Kernel nicht interpretierte
Byte-Folgen' ist Ansichtssache (ich habe dazu keine, denn als
Anwendungsentwickler, der ich nun mal groesstenteils bin, ist mir
'Kernel-Aesthetik' eigentlich egal und ich bin auch bereit, die
Benutzung zweiblaettriger Saegen mit Mittelgriff zu erlernen, solange
diese drei Teile nicht alle zwei Tage nach Massgabe einer anderen Mode
umarrangiert oder umgeformt werden :->).
> Wenn der Datenaustausch schnell gehen soll, ist in dem Fall shared
> memory vern锟絥ftig, oder ist ein anderer Weg vorzuziehen?
Wenn der Datenaustausch 'schnell' gehen soll, dann sollte man ihn nach
Moeglichkeit vermeiden. Ob die Anwendung Daten in einen shared-memory
Bereich kopiert, oder der Kernel Anwendungsdaten in 'kernel memory'
duerfte keinen grossen Unterschied machen. Ein Vorteil waere denkbar,
falls der Kernel 'Massendaten', also zB IP-Datagramme oder Audio-/
Videoframes von 'irgendwelchen Geraeten' empfaengt und eine Anwendung
diese 'irgendwie' verarbeiten soll. Insofern ein gemeinsamer Puffer
benutzt werden kann, koennte man dadurch ein oder zwei Kopien des
kompletten Datenstroms einsparen. Hier waeren allerdings die Kosten
fuer die Rekonfiguration der Anwendungs-VM zu beruecksichtigen, vor
allem fuer SMP-Systeme (ich weiss selber, dass das allgemeines Gelaber
ist :-). Allerding wird eine 08/15-Anwendungen sowieso jedes 'Datum'
ebenso fortwaehrend wie vermeidbar in der Gegend herumkopieren,
insofern sollte man das etwas cum grano salis sehen.
Die Frage ist etwas arg allgemein, um eine sinnvolle Antwort, die
nicht einem ganzen Buch entspricht, geben zu koennen.
Rainer Weikusat
[...]
> Fuer Linux gilt es mittlerweile (soweit mir das bekannt ist) als comme
> il faut, fuer diese Art von Kommunikation 'character device'-Treiber
> zu benutzen,
Das ist natuerlich totaler Unfug, denn 'open', also letztlich
Benutzung des Dateisystem-Namensraums um bestimmte Kernel-Features
ansprechen zu koennen, wird ausruecklich nicht als erwuenscht
angesehen (zB war epoll mal ein character device), es werden hingegen
neue Systemaufrufe hinzugefuegt, die auch Dateibeschreiber
zurueckgeben und die zwar als spezialisierte Dateien referenzierend
angesehen werden koennen, aber nur konzeptuell.
Martin Freiberg
Hallo,
> Fuer Linux gilt es mittlerweile (soweit mir das bekannt ist) als comme
> il faut, fuer diese Art von Kommunikation 'character device'-Treiber
> zu benutzen, vgl epoll, signalfd, timerfd. Die 'traditionelle'
> UNIX(*)-Methode dafuer waere ioctl. Ob man open/ read/ write/ close/
Dumme Frage meinerseits: F�r die Kommunikation �ber ioctl mu� ich doch
ein device anlegen. Also z.B. ein character device, das nur die ioctl
Funktionen zur Verf�gung stellt. Sollte so etwas also nun als block
device angelegt werden? Oder gibt es dazu nun eine dritte Einordnung,
wenn man nur ioctl zur Verf�gung stellt?
>> Wenn der Datenaustausch schnell gehen soll, ist in dem Fall shared
>> memory vern�nftig, oder ist ein anderer Weg vorzuziehen?
> Wenn der Datenaustausch 'schnell' gehen soll, dann sollte man ihn nach
> Moeglichkeit vermeiden. Ob die Anwendung Daten in einen shared-memory
OK, schnell ist hier relativ. Ich bin eben von fr�her her gewohnt, jedes
unn�tige hin-, und her-kopieren von Daten zu vermeiden, die Resourcen
bestm�glich auszunutzen. Bei den heutigen Prozessoren ist die
umst�ndlichste Art noch mehr als schnell genug. Aber der Ehrgeiz ein
Programm bestm�glich zu optimieren ist noch tief verwurzelt.
Und f�r private Basteleien und �bungen muss ich nicht auf
schnellstm�gliches "hinschmieren" eines Programmes optimieren. Hier
spielt der Zeitfaktor nur eine untergeordnete Rolle.
> diese 'irgendwie' verarbeiten soll. Insofern ein gemeinsamer Puffer
> benutzt werden kann, koennte man dadurch ein oder zwei Kopien des
> kompletten Datenstroms einsparen. Hier waeren allerdings die Kosten
> fuer die Rekonfiguration der Anwendungs-VM zu beruecksichtigen, vor
Ja, hier kommt der Unterschied zu tragen, ob ein Produkt
schnellstm�glich auf dem markt zu Verkaufen sein soll, oder ob
liebevolles Basteln und Optimieren noch erlaubt sind.
Gru�
Martin
Rainer Weikusat
> Rainer Weikusat schrieb:
>> Fuer Linux gilt es mittlerweile (soweit mir das bekannt ist) als comme
>> il faut, fuer diese Art von Kommunikation 'character device'-Treiber
>> zu benutzen, vgl epoll, signalfd, timerfd. Die 'traditionelle'
>> UNIX(*)-Methode dafuer waere ioctl. Ob man open/ read/ write/ close/
>
> ein device anlegen. Also z.B. ein character device, das nur die ioctl
> device angelegt werden? Oder gibt es dazu nun eine dritte Einordnung,
Grundsaetzlich kann auch ein 'spezialisiertes open' (s. anderes
Posting) ioctl anbieten.
>>> Wenn der Datenaustausch schnell gehen soll, ist in dem Fall shared
>>> memory vern�ｿｽnftig, oder ist ein anderer Weg vorzuziehen?
>> Wenn der Datenaustausch 'schnell' gehen soll, dann sollte man ihn nach
>> Moeglichkeit vermeiden. Ob die Anwendung Daten in einen shared-memory
>
> OK, schnell ist hier relativ. Ich bin eben von fr�ｿｽher her gewohnt,
> jedes unn�ｿｽtige hin-, und her-kopieren von Daten zu vermeiden,
Genau darum ging es ja: Ein 'shared memory'-Bereich KANN zB einfach
als Datenaustauschpuffer genutzt werden und DANN waere das
wahrscheinlich nicht schneller, die Daten von der Anwendung in den
gemeinsamen Puffer kopieren zu lassen als vom kernel in einen
Kernel-Puffer. Das hatte ich uebrigens genaus so bereits geschrieben.
[...]
>> diese 'irgendwie' verarbeiten soll. Insofern ein gemeinsamer Puffer
>> benutzt werden kann, koennte man dadurch ein oder zwei Kopien des
>> kompletten Datenstroms einsparen. Hier waeren allerdings die Kosten
>> fuer die Rekonfiguration der Anwendungs-VM zu beruecksichtigen, vor
>
> Ja, hier kommt der Unterschied zu tragen, ob ein Produkt
> schnellstm�ｿｽglich auf dem markt zu Verkaufen sein soll, oder ob
> liebevolles Basteln und Optimieren noch erlaubt sind.
Hier kommt der Umstand zum tragen, das bei einer VM-Rekonfiguration,
dh einer Aenderung der Seitenbeschreibertabellen fuer diese Anwendung
im Kernel eventuell ein IPI an alle Prozessoren gesendet werden muss.
Herzlichen Dank uebrigens fuer die vollkommen ungerechtfertigte
Unterstellung. So macht das Beantworten von Anfaengerfragen erst
richtig Spass ...
Martin Freiberg
> Martin Freiberg <ly...@web.de> writes:
> Herzlichen Dank uebrigens fuer die vollkommen ungerechtfertigte
> Unterstellung. So macht das Beantworten von Anfaengerfragen erst
> richtig Spass ...
??? Auf was beziehst Du das?
Ist es etwa nicht so, dass die Vorgesetzten ein angefordertes Programm
am liebsten schon fertig sehen w�rden, w�hrend sie einem den "Wunsch"
mitteilen?
Oder meinst Du etwas anderes? Ich sehe im Moment nichts, wo ich jemandem
etwas bewusst Unterstelle.
Gru�
Martin
Rainer Weikusat
> Rainer Weikusat schrieb:
>> Martin Freiberg <ly...@web.de> writes:
>
>> Herzlichen Dank uebrigens fuer die vollkommen ungerechtfertigte
>> Unterstellung. So macht das Beantworten von Anfaengerfragen erst
>> richtig Spass ...
>
> ??? Auf was beziehst Du das?
>
> Ist es etwa nicht so, dass die Vorgesetzten ein angefordertes Programm
> am liebsten schon fertig sehen w�rden, w�hrend sie einem den "Wunsch"
> mitteilen?
Auf Deine Mutmassung, meine allgemeinen Bemerkungen zum Thema 'shared
memory' (beim ersten Zugriff auf eine 'neue' Seiteneinblendung gibt es
ausserdem noch einen page fault) haetten sich gar nicht auf 'shared
memory' bezogen, sondern ein Beduerfnis zum 'schnnellen Hinschmieren'
von Programmen zum Ausdruck bringen sollen. Letzteres ist uebrigens
allgemein eine Fehlannahme: Es dauert immer laenger, Code zu debuggen,
als ihn zu schreiben und je mehr man beim schreiben 'aus Zeitgruenden'
geschludert hat, desto mehr Zeit braucht man dann auch, um das ohne
Not technisch schlechte Produkt[*] wenigstens in einen einigermassen
benutzbaren Zustand zu versetzen.
[*] Das soll eine technische Aussage sein. Mir ist klar, dass
die 'Not' haeufig daher ruehrt, das jemand ueberhaupt erst mal
etwas wenigstens theoretisch einigermassen funktionstuechtiges
zuwege bringen muss.
Martin Freiberg
> Martin Freiberg <ly...@web.de> writes:
> Auf Deine Mutmassung, meine allgemeinen Bemerkungen zum Thema 'shared
> memory' (beim ersten Zugriff auf eine 'neue' Seiteneinblendung gibt es
> ausserdem noch einen page fault) haetten sich gar nicht auf 'shared
> memory' bezogen, sondern ein Beduerfnis zum 'schnnellen Hinschmieren'
Ups, Sorry, da h�tte ich wohl genauer formulieren sollen. Das mit dem
"hinschmieren" war und ist in keiner Weise auf deine Antwort bezogen
(Weder Schreibstil, Inhalt oder Aussage).
Mit "hinschmieren" wollte ich nur zum Ausdruck bringen das man durch den
zeitlichen Druck, den man beim kommerziellen programmieren hat, doch gar
keine Zeit mehr zum optimieren hat.
Lies den Abschnitt bitte nochmal unter dieser Aussage. :-)
> allgemein eine Fehlannahme: Es dauert immer laenger, Code zu debuggen,
> als ihn zu schreiben und je mehr man beim schreiben 'aus Zeitgruenden'
Schon richtig. So viel "Sauberkeit" muss sein.
Aber das optimieren bleibt doch vielfach auf der Strecke.
W�rde einem die Zeit zum Optimieren bleiben, dann w�rde man wohl
sicherlich manchen Abschnitt verwerfen und nochmals neu erstellen.
Letztlich ist das Programm fehlerfrei [*] und funktioniert wie
gew�nscht, aber von Optimal und optimiert d�rften die meisten
Programme noch meilenweit entfernt sein.
[*] Wirklich fehlerfrei wird wohl ein Programm nie sein.
Gru�
Martin