Ich habe eine allgemeine Frage zur Linux Programmierung in C. Ab wann
genau fängt die Programmierung von Anwendungen an und ab wann die des
Kernels. Ich habe zwei, meiner Meinung nach gute Bücher gefunden: The
Linux Programming Interface: A Linux and UNIX System Programming
Handbook und Linux System Programming: Talking Directly to the Kernel
and C Library. Kennt jemand beide Bücher? Das zweite finde ich für
Einsteiger sogar etwas verständlicher.
Mich interessieren insbesondere die Themen timer/timerfd, epoll, posix
message queues und sockets. Leider ist mir bei der Verwendung der
entsprechenden Funktionen nicht klar, ob ich da mit einem timerfd oder
eine POSIX message queues bereits Kernel programmierung betreibe oder es
eher Anwendungs programmierung ist. Kann mir jemand diese Frage
beantworten?
Kann mir jemand bei Gelegenheit auch sagen, was den Unterschied zwischen
Sockets und message queues ist ? Mit sockets kann ich auch nachrichten
senden und über eine zweite shell empfangen.
Danke euch vorab!
Kernelprogrammierung fängt an wenn Du:
-die Kernelsource änderst
-oder code schreibst der in den Kernel kompiliert wird
-oder ein Kernelmodul schreibst (dass dann mit insmod oder Ähnlichem)
geladen wird.
Wahrscheinlich kommt die Verwirrung weil man heutzutage ein Application
Framework benutzt, diese Funktionen nicht mehr direkt aufruft. Früher
hatten alle Anwendungsprogramme diese Funkionen ohne Zwischenschicht
direkt benutzt.
Nach der alten Definition war es ganz einfach:
Wenn du die diese Funktionen verwendest, ist es
Anwendungsprogrammierung. Wenn du sie selbst implementierst, ist es
Systemprogrammierung.
Heutzutage bezeichnet man aber auch die Zwischenschicht als
Systemprogrammierung.
Kernelprogrammierung (danach war ja gefragt) ist aber beides nicht.
LNX schrieb:> Kann mir jemand bei Gelegenheit auch sagen, was den Unterschied zwischen> Sockets und message queues ist ? Mit sockets kann ich auch nachrichten> senden und über eine zweite shell empfangen.
Mit Sockets kann man aber auch Netzwerk- oder Bluetooth- oder
CAN-Kommunikation machen. Message Queues sind immer lokal auf einem
Rechner.
LNX schrieb:> Ab wann> genau fängt die Programmierung von Anwendungen an und ab wann die des> Kernels.
Wenn du diese Frage stellst, ist das was du tust immer
Anwendungsentwicklung.
Man kann nicht versehentlich Kernelprogrammierung tun.
LNX schrieb:> Ich habe eine allgemeine Frage zur Linux Programmierung in C. Ab wann> genau fängt die Programmierung von Anwendungen an und ab wann die des> Kernels. Ich habe zwei, meiner Meinung nach gute Bücher gefunden: The> Linux Programming Interface: A Linux and UNIX System Programming> Handbook und Linux System Programming: Talking Directly to the Kernel> and C Library. Kennt jemand beide Bücher?
Beide Bücher sind leider bereits relativ alt und bearbeiten weniger die
Kernelprogrammierung, sondern eher die Entwicklung von Systemsoftware im
Userland. Dabei werden einige Systemfunktionen wie fork(2) genutzt, aber
vor allem Standardfunktionen aus der C-Standardbibliothek vorgestellt.
Dem Alter geschuldet dürfte sein, daß ich im zweiten Buch zwar fork(2)
und das neuere vfork(2), allerdings leider nicht die aktuellere Funktion
clone(2) gefunden habe, welche zusätzlich zu dem, was vfork(2) bietet,
auch Linux Namespaces (zB. für Docker, LXC) unterstützt.
> Kann mir jemand bei Gelegenheit auch sagen, was den Unterschied zwischen> Sockets und message queues ist ? Mit sockets kann ich auch nachrichten> senden und über eine zweite shell empfangen.
Sockets gehören zur Basisfunktionalität moderner Betriebssysteme und
sind meistens auf Kernelebene implementiert, während Message Queues
lediglich eine Middleware sind, also eine im Userspace laufende
Anwendung.
Sie dienen beide der Kommunikation zwischen Prozessen oder Threads, aber
während Sockets die interne Repräsentation eines
Kommunikationsendpunktes darstellen, sind Message Queues (meist) Teil
einer nachrichtenorientierten Middleware. Message Queues benutzen
meistens Sockets, bieten aber darüber hinaus auch noch eine
Zwischenspeicherung der Nachrichten und bieten dazu einen FIFO-Puffer,
der für Append-Zugriffe an seinem Ende und Pop-Zugriffe an seinem Anfang
optimiert ist -- im Kern sind sie also Warteschlangen.
Anders gesagt: über Sockets können nur zwei Prozesse (oder Threads)
kommunizieren, die gleichzeitig auf den Socket zugreifen. Bei Message
Queues ist das nicht notwendig: hier stellt ein Prozeß seine Nachrichten
ein, und ein anderer Prozeß kann sie später -- wenn der erste Prozess
vielleicht schon längst beendet ist -- abholen und weiterverarbeiten.
Sheeva P. schrieb:> Dem Alter geschuldet dürfte sein, daß ich im zweiten Buch zwar fork(2)> und das neuere vfork(2), allerdings leider nicht die aktuellere Funktion> clone(2) gefunden habe, welche zusätzlich zu dem, was vfork(2) bietet,> auch Linux Namespaces (zB. für Docker, LXC) unterstützt.
Dafür ist die Funktion Linux-spezifisch, während fork() eine
POSIX-Funktion und somit portabel ist. Gut, könnte man in einem
Linux-Programmierbuch natürlich erwähnen. So neu dürfte clone() auch
nicht sein, denn darüber sind unter Linux auch Threads umgesetzt.
>> Kann mir jemand bei Gelegenheit auch sagen, was den Unterschied zwischen>> Sockets und message queues ist ? Mit sockets kann ich auch nachrichten>> senden und über eine zweite shell empfangen.>> Sockets gehören zur Basisfunktionalität moderner Betriebssysteme und> sind meistens auf Kernelebene implementiert, während Message Queues> lediglich eine Middleware sind, also eine im Userspace laufende> Anwendung.
Nein, zumindest unter Linux sind die Funktionen für message queues
(sowohl POSIX als auch SysV) als eigene system calls umgesetzt.
Rolf M. schrieb:> Dafür ist die Funktion Linux-spezifisch, während fork() eine> POSIX-Funktion und somit portabel ist.
Richtig, aber bei den genannten Büchern geht es ausdrücklich um Linux.
Da kann man wohl kaum den modernsten, effizientesten und flexibelsten
System Call außen vor lassen, oder?
> Nein, zumindest unter Linux sind die Funktionen für message queues> (sowohl POSIX als auch SysV) als eigene system calls umgesetzt.
Das ist bekannt. Nicht bekannt ist mir eine Software, die diese Calls
verwendet. Und wenn Du eine bessere Erklärung für den TO hast, um den
Unterschied zwischen Message Queues und Sockets zu erklären: gern. ;-)
Sheeva P. schrieb:> Rolf M. schrieb:>> Dafür ist die Funktion Linux-spezifisch, während fork() eine>> POSIX-Funktion und somit portabel ist.>> Richtig, aber bei den genannten Büchern geht es ausdrücklich um Linux.> Da kann man wohl kaum den modernsten, effizientesten und flexibelsten> System Call außen vor lassen, oder?
Deshalb schrieb ich ja:
Rolf M. schrieb:> Gut, könnte man in einem Linux-Programmierbuch natürlich erwähnen.>> Nein, zumindest unter Linux sind die Funktionen für message queues>> (sowohl POSIX als auch SysV) als eigene system calls umgesetzt.>> Das ist bekannt. Nicht bekannt ist mir eine Software, die diese Calls> verwendet.
Ich kenne eine Echtzeit-Software, die das tut. Da scheint das auch am
häufigsten zum Einsatz zu kommen. Deshalb steckt das auch in der librt
und nicht in der libc.
> Und wenn Du eine bessere Erklärung für den TO hast, um den Unterschied> zwischen Message Queues und Sockets zu erklären: gern. ;-)
Hier sind ein paar Punkte:
https://users.pja.edu.pl/~jms/qnx/help/watcom/clibref/mq_overview.html
Da wird zwar nicht mit Sockets, sondern mit Pipes vergleichen, aber die
Punkte gelten für Sockets gleichermaßen.
Das hier scheint auch lesenswert:
http://man7.org/tlpi/download/TLPI-52-POSIX_Message_Queues.pdf
