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
Rolf M. schrieb: > 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 Erste Wahl ist immer da Original: APUE Und: TLPI (wurde schon genannt)
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.