Hallo Leute, es gibt eine schöne Wiki-Seite dazu: >Ports benutzen (GCC) >Aus der Mikrocontroller.net Artikelsammlung, mit Beiträgen verschiedener >Autoren (siehe Versionsgeschichte) >Über die Ansteuerung der Schnittstellen unter Linux findet man im Internet >überall etwas anderes. Die einen sagen, man soll die Schnittstellen über ihre >I/O-Adresse (0x3F8,0x2F8,0x378,...) ansteuern, allerdings ist das nicht >portabel und funktioniert nur mit Root-Rechten. Ich habe anscheinend Probleme mit den Zugriffrechten, was im Artikel auch erwähnt ist. Leider wird für die Änderung der Rechte auf einen Link verwiesen, wêlcher nicht mehr aktuell ist: >Damit der User auf die Schnittstellen zugreifen kann, muss er in die Gruppen >"lp" und "dialout" eingetragen werden. Wie das funktioniert kann man hier >nachlesen: http://www.tuxhausen.de/kurs_user.html Kann mir da jemand weiterhelfen?
Rolf E. schrieb: > Kann mir da jemand weiterhelfen? Was willst du denn genau machen? Serielle Schnittstelle oder Parallele? Echte "alte" PC-Kompatible Schnittstelle vorhanden oder was neueres (PCIe, USB, ...?) Oder geht es dir nur um die Rechtevergabe? Auch da gäbs verschiedene Wege, z.B. zuerstmal per "ls -la /dev/parport* /dev/ttyS* /dev/ttyUSB* /dev/ttyACM*" etc nachschauen, welche Gruppen usw. da von deiner Distribution Zugriff haben, und deinen User in die Gruppe packen. oder "sudo" verwenden. oder die device-Nodes World-writable machen. oder dir geben. entweder manuell oder per udev, ....
:
Bearbeitet durch User
Rolf E. schrieb: > Leider wird für die Änderung der Rechte auf einen Link > verwiesen, wêlcher nicht mehr aktuell ist: > >>Damit der User auf die Schnittstellen zugreifen kann, muss er in die Gruppen >>"lp" und "dialout" eingetragen werden. Wie das funktioniert kann man hier >>nachlesen: http://www.tuxhausen.de/kurs_user.html > > Kann mir da jemand weiterhelfen? Google kaputt? Na ok, weil heute Freitag ist:
1 | sudo usermod -aG lp,dialout rolf |
... wenn du den Benutzer rolf den genannten Gruppen hinzufügen möchtest. Danach ist einmal ab- und wieder anmelden angesagt, eine Neustart tut's natürlich auch.
Heiner schrieb: > sudo usermod -aG lp,dialout rolf Hilft aber nicht, dass der Benutzer rolf unter Linux auf Rolf E. schrieb: >I/O-Adresse (0x3F8,0x2F8,0x378,...) Zugreifen darf. Insofern bleibt die Frage, was der Rolf eigentlich erreichen will.
Εrnst B. schrieb: > Hilft aber nicht, dass der Benutzer rolf unter Linux auf > > Rolf E. schrieb: >>I/O-Adresse (0x3F8,0x2F8,0x378,...) > > Zugreifen darf. Das kann man über eine Gruppe GPIO und eine entsprechende UDEV-Regel machen
Εrnst B. schrieb: > Hilft aber nicht, dass der Benutzer rolf unter Linux auf > > Rolf E. schrieb: >>I/O-Adresse (0x3F8,0x2F8,0x378,...) > > Zugreifen darf. Das hat auch niemand behauptet. Stattdessen mal etwas Lesekompetenz: Er versucht diese Anleitung nachzuvollziehen: https://www.mikrocontroller.net/articles/Ports_benutzen_(GCC) (Ja, das hätte man verlinken können, statt nur die ersten Sätze zu kopieren.) Diese Anleitung enthält einen defekten Link. Die dort enthaltene relevante Information findest du in meinem Beitrag. Man hätte es auch so wie tuxxi machen können und den aktuellen Link nachliefern. Ein angemeldeter Benutzer könnte nun z.B. den Artikel verbessern, durch den aktuellen Link oder indem man für einen derartigen Einzeiler nicht auf externe Quellen verweisen muss. Das wäre besser als hier Grundsatzdiskussionen anzufangen: Εrnst B. schrieb: > Insofern bleibt die Frage, was der Rolf eigentlich erreichen will. Wenn er das (konkreter als in der Überschrift) wüsste, müsste er nicht fragen. Insofern könnte man einfach die unmittelbare Frage beantworten.
Heiner schrieb: > Insofern könnte man einfach die unmittelbare Frage beantworten. Langfristig ist ihm mehr geholfen, wenn er lernt saubere Fragen zu stellen, wie man Artikel verlinkt, was Device-Nodes sind, was User/Gruppen/World Rechte auf Dateien aussagen, wie man Gruppenmitgliedschaften unter Linux steuert usw. Was wenn bei ihm die gewünschten Device-Nodes der Gruppe "plugdev" gehören, und nicht dialout? Nachschauen-Nachdenken-Machen ist doch wohl besser als: Google, kopier alles was du findest in die root-shell, solange bis irgendas funktioniert oder du neuinstallieren musst.
Hallo nochmals, Ja, das mit dem Verlinken des Orginalbeitrags habe ich danach auch gesehen. Ich möchte mit einem Terminalprogramm (z.B. SerialPorter) auf den Port ttyUSB0 zugrefen, Bekomme jedoch eine Fehlermeldung, dass ich keine Zugriffsrechte habe. Hatte schon mit chmod die Rechte unter /dev geändet, dann lief es bis zur nächsten Anmeldung. Dann war es zurückgesetzt. Jetzt habe ich endlich, nach langem Suchen diesen Artikel gefunden, der diese Anleitung enthalten sollte. Alle Anderen unterschlagen diesen Aspekt. Daher der Frust über diesen Link. Auf der Seite von tuxxi hatte ich dann nur diesen alg. Linux-Kurs gesehen. Bei dessen Kapitelübersicht habe ich auf Anhieb nichts gesehen, was meinem Problem entspricht. (Bin neu bei Linux). Werde dann noch dem Hinweis von Werner folgen. Mal sehen, ob das funktioniert.
mach mal nach einem Reboot folgendes im Terminal: ls -l /dev/tty* und stelle das Ergebnis hier ein.
hier der gewünschte output (teil) ls -l /dev/tty* crw-rw---- 1 root dialout 4, 73 Feb 20 15:46 /dev/ttyS9 crw-rw---- 1 root dialout 188, 0 Feb 20 15:46 /dev/ttyUSB0 Anscheinend müsste ich Mitglied der Gruppe dialout werden um auf ttyUSB0 zuzugreifen. das sollte vermutlich mit dem von Heiner vorgeschlagenen Befehl sudo usermod -aG lp,dialout rolf gehen geht jedoch nicht groups rolf_admin adm cdrom sudo dip plugdev lpadmin lxd sambashare
Du hast dich danach komplett aus- und wieder eingeloggt? Vorher werden Änderungen der Gruppenzugehörigkeit nicht wirksam. lp würde ich weglassen, btw.
probier mal das: sudo usermod -aG dialout rolf dann abmelden und wieder anmelden und dann groups
Hallo tuxxi schrieb: > probier mal das: > > sudo usermod -aG dialout rolf > > dann abmelden und wieder anmelden und dann > > groups normalo lp dialout (normalo bin ich als nicht root) so geht's bei mir. Terminalprogramm läuft auch Vielen Dank an alle! (da mein Google nicht läuft)
Rolf E. schrieb: > Jetzt habe ich endlich, nach langem Suchen diesen Artikel gefunden, der > diese Anleitung enthalten sollte. Alle Anderen unterschlagen diesen > Aspekt. Daher der Frust über diesen Link. Bitte verzeih', aber die "unterschlagen diesen Aspekt" keineswegs, sondern setzen ihn als minimales Grundlagenwissen einfach voraus. > Auf der Seite von tuxxi hatte ich dann nur diesen alg. Linux-Kurs > gesehen. Bei dessen Kapitelübersicht habe ich auf Anhieb nichts gesehen, > was meinem Problem entspricht. (Bin neu bei Linux). Ja, genau, Du bist neu. Wenn ich Dir einen guten Rat geben darf: bevor Du Dich an Lösungen für konkrete Probleme begibst, wäre es extrem sinnvoll, Dir zunächst die Grundlagen von Linux zu erarbeiten. Als absolutes Minimum würde ich da empfehlen: - Verzeichnisstruktur - Benutzer- und Rechteorganisation - die bash-Shell Für einen oberflächlichen Einstieg möchte ich Dir zwei Links ans Herz legen, [1] und [2]. Wenn Du die gelesen hast, wirst Du dem System und der Lösung Deines aktuellen, sowie vieler zukünftiger Probleme schon deutlich näher gekommen sein. Wenn Du Dich hingegen ernsthaft mit dem System und seinen Fähigkeiten auseinandersetzen möchtest, möchte ich Dir [3] und [4] empfehlen, und wenn Du lieber ein paar Euro erübrigen und ein gutes Buch lesen möchtest, empfehle ich [5]. Speziell für die systemnahe C-Programmierung und die Netzwerkprogrammierung gibt es auf englich immer noch die hervorragengen Bücher von W. Richard Stevens. Früher gab es die auch in deutschen Übersetzungen -- keine Ahnung, ob das noch so ist... [1] https://www.ernstlx.com/linux90linux.html [2] http://openbook.rheinwerk-verlag.de/linux/linux_kap06_001.html [3] https://debiananwenderhandbuch.de/ [4] https://debian-handbook.info/browse/de-DE/stable/ [5] https://kofler.info/buecher/linux/
Hallo nochmals, einen Einführungkurs über bash und Verzeichnisstruktur habe ich anhand von der Ubuntu-Website schon gemacht, auch weiss ich, dass es ZugriffsRechte und Gruppen für Filezugriffe gibt. Dass sich das aber auch auf Devices bezieht, war mir entgangen. Ich werde mich dann gerne noch vertiefter einlesen, hatte jedoch hier noch ein akutes Problem, da ich noch ein altes Entwicklungssystem über RS-232 betreibe, um mein Gross-Nixie-Uhr-Projekt voranzutreiben. Beitrag "Re: Zeigt her eure Kunstwerke (2021)" https://c.gmx.net/@334631847457723762/7y8a-__dQjKLtZmHCBad3w danke für die Links zum Nachlesen, werde ich gerne verwenden!
Rolf E. schrieb: > Dass sich das aber auch auf Devices bezieht, war mir entgangen. Gerätedateien (device nodes) sind halt rechtemäßig erst einmal ganz normale Dateien. Daher funktionieren Nutzer- und Gruppenrechte auf ihnen. (Intern können sie natürlich weitere Restriktionen beinhalten, insbesondere kann ein Treiber verlangen, dass bestimmte Aktionen nur durch den Superuser durchführbar sind.)
Rolf E. schrieb: > auch weiss ich, dass es > ZugriffsRechte und Gruppen für Filezugriffe gibt. Dass sich das aber > auch auf Devices bezieht, war mir entgangen. „everything is a file“. Wenn du mal viel Langeweile hast, schau mal in /proc rein ;)
Moin moin Jack V. schrieb: > „everything is a file“. Wenn du mal viel Langeweile hast, schau mal in > /proc rein ;) Unterdessen weiss ich das auch, ich hatte auch schon zu Beginn versucht, die Zugriffsrechte filemässig auf alle zu erweitern <chmod 777>, was jedoch nicht von Dauer war. Jetzt geht es ja und wenn ich mich dann durchgelesen habe, sehe ich vielleicht noch andere Möglichkeiten.
Rolf E. schrieb: > die Zugriffsrechte filemässig auf alle zu erweitern <chmod 777>, was > jedoch nicht von Dauer war Davon abgesehen, dass man so einen "Rundumschlag" bestenfalls mal zum Ausprobieren macht: alle heutigen Unixe benutzen für /dev ein dynamisch erstelltes Dateisystem, welches eine Ansicht der Gerätedateien bietet, die von den entsprechenden Kerneltreibern erzeugt wird. Das Problem früherer statisch konfigurierter Gerätedateien war halt, dass niemand garantieren konnte, dass sie auch zu den tatsächlich vorhandenen Geräten passten. Da konnten Gerätedateien existieren, für die gar kein Treiber konfiguriert war, oder aber es waren Treiber erfolgreich geladen, für die nie jemand eine Gerätedatei angelegt hat, sodass man nicht drauf zugreifen konnte. Durch dieses device filesystem sind diese Diskrepanzen behoben, aber dafür muss man sich halt auch dynamisch drum kümmern, wie die Rechte der entsprechenden Gerätedateien aussehen. Unter Linux erledigt dies das "udev" genannte Subsystem. Die entsprechenden Konfigurationsdateien stehen dann unterhalb /etc/udev/, und Dateien in /etc/udev/rules.d/ kümmern sich darum, beim Erscheinen von Geräten (bspw. am USB) die entsprechenden Zugriffsrechte zu organisieren.
Rolf E. schrieb: > Moin moin > > Jack V. schrieb: >> „everything is a file“. Wenn du mal viel Langeweile hast, schau mal in >> /proc rein ;) > > Unterdessen weiss ich das auch, ich hatte auch schon zu Beginn versucht, > die Zugriffsrechte filemässig auf alle zu erweitern <chmod 777>, was > jedoch nicht von Dauer war. Jetzt geht es ja und wenn ich mich dann > durchgelesen habe, sehe ich vielleicht noch andere Möglichkeiten. Unter Linux werden die Einträge in /dev seit längerem automatisch durch udev erzeugt, wenn ein entsprechendes Gerät gefunden wird. Dadurch bedingt werden auch die Berechtigungen darüber definiert. Du müsstest also zum permanenten Ändern der Berechtigung die entsprechende udev-Regel suchen und das dort ändern. Aber die meisten Geräte haben bereits über die Gruppenzuordnung die Möglichkeit, sie selektiv für einzelne Benutzer freizuschalten, so das das Anfassen der udev-Rules dafür in der Regel nicht nötig ist.
Rolf M. schrieb: > Unter Linux werden die Einträge in /dev seit längerem automatisch durch > udev erzeugt, wenn ein entsprechendes Gerät gefunden wird. Sowas hatte ich mir aufgrund des Verhaltens dann gedacht. Das mit chmod 777 war einfach einmal ein Versuch, um auf die sichere Seite zu kommen. Die Tatsache, dass die Files in /dev eine Länge von 0 Bytes haben, liess schon vermuten, dass die auf etwas anderes Zeigen und irgendwo erzeugt werden. da ich jedoch dieses System nicht kannte, und mit Yahoo! nichts vernünftiges fand, fragte ich hier.
Rolf E. schrieb: > Die Tatsache, dass die Files in /dev eine Länge von 0 Bytes haben Device nodes (Gerätedateien) haben keine „Länge“.
Rolf E. schrieb: > einen Einführungkurs über bash und Verzeichnisstruktur habe ich anhand > von der Ubuntu-Website schon gemacht, auch weiss ich, dass es > ZugriffsRechte und Gruppen für Filezugriffe gibt. Dass sich das aber > auch auf Devices bezieht, war mir entgangen. Das ist unter UNIX-artigen Betriebssystemen, wie Linux eines ist, gleich. Der Merksatz ist, daß unter UNIX alles eine Datei ist. Jedes Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. Sogar der Hauptspeicher Deines Rechners wird unter /dev/mem als virtuelle Datei abgebildet. Das ist eine große Stärke von UNIXoiden, denn somit lassen sich die klassischen UNIX-Zugriffsrechte eben auch auf Geräte, Sockets, etc. abbilden. Viel Spaß und Erfolg mit meinen Links! ;-)
Sheeva P. schrieb: > Jedes Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. Sockets? Nur bei local domain. Und über SYSVIPC reden wir besser nicht. :-)
Rolf E. schrieb: > Unterdessen weiss ich das auch, ich hatte auch schon zu Beginn versucht, > die Zugriffsrechte filemässig auf alle zu erweitern <chmod 777>, was > jedoch nicht von Dauer war. Das wäre unter älteren Linux-Kernels auch gegangen, da waren die Device-Nodes nämlich noch echte Dateien im Verzeichnis dev, und zum Teil mußte man sie sogar manuell (und korrekt) anlegen, um neu verbaute Hardware ansprechen zu können. Mittlerweile hat Linux allerdings eine automatische Hardware-Erkennung und natürlich Hotplugging-Fähigkeiten bekommen, deswegen ist das alte, starre System durch den udev-Daemon abgelöst worden, der das Verzeichnis dev mit den Gerätedateien dynamisch beim Booten und natürlich bei Hotplug-Events erzeugt. Deswegen gehen bei einem Reboot die Dateiberechtigungen verloren; um sie zu persistieren, kann man allerdings eigene udev-Regeln in /etc/udev/rules.d/ anlegen.
Sheeva P. schrieb: > Das ist unter UNIX-artigen Betriebssystemen, wie Linux eines ist, > gleich. Der Merksatz ist, daß unter UNIX alles eine Datei ist. Jedes > Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. Netzwerk-Geräte (wie z.B. eth0) jedoch lustigerweise nicht. Jörg W. schrieb: > Sheeva P. schrieb: >> Jedes Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. > > Sockets? Nur bei local domain. Kommt drauf an, von wo man schaut. Sie sind keine inodes in einem Filesystem, aber ein geöffneter socket kann mit genau den gleichen Funktionen genutzt werden, wie eine Datei (abgesehen natürlich von so Dingen wie lseek()).
Rolf M. schrieb: > Sie sind keine inodes in einem Filesystem, aber ein geöffneter socket > kann mit genau den gleichen Funktionen genutzt werden, wie eine Datei Das ist aber was anderes als Gerätedateien. Ja, Dateideskriptoren benutzen sie auch – im Gegensatz übrigesn zur genannten SYSVIPC.
Sheeva P. schrieb: > Das ist unter UNIX-artigen Betriebssystemen, wie Linux eines ist, > gleich. Der Merksatz ist, daß unter UNIX alles eine Datei ist. Jedes > Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. Ja, unter Linux ist alles eine Datei, aber manches ist leider dateier. (Frei nach Orwell).
Jörg W. schrieb: > Rolf M. schrieb: >> Sie sind keine inodes in einem Filesystem, aber ein geöffneter socket >> kann mit genau den gleichen Funktionen genutzt werden, wie eine Datei > > Das ist aber was anderes als Gerätedateien. Ja, klar. Aber im Prinzip kann man das auch als Teil der "alles ist eine Datei"-Philosophie sehen. Wenn ich's erst mal geöffnet habe, kann ich in den Socket genau auf die gleiche Weise schreiben wie in eine Datei, und ich kann z.B. per select() oder poll() gleichzeitig auf einen Socket, eine Pipe und ein Gerät warten. > Ja, Dateideskriptoren benutzen sie auch – im Gegensatz übrigesn zur > genannten SYSVIPC. Allerdings.
Rolf M. schrieb: > Sheeva P. schrieb: >> Das ist unter UNIX-artigen Betriebssystemen, wie Linux eines ist, >> gleich. Der Merksatz ist, daß unter UNIX alles eine Datei ist. Jedes >> Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. > > Netzwerk-Geräte (wie z.B. eth0) jedoch lustigerweise nicht. ... mehr. Bei frühen Linux-Kernels war das anders, und unter SunOS / Solaris auch. Unter moderneren Linux-Kernels findet man die Geräte in der Datei /proc/net/dev und die Schnettstillen im Verzeichnis /sys/class/net/, IIRC. > Jörg W. schrieb: >> Sheeva P. schrieb: >>> Jedes Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. >> >> Sockets? Nur bei local domain. > > Kommt drauf an, von wo man schaut. Sie sind keine inodes in einem > Filesystem, aber ein geöffneter socket kann mit genau den gleichen > Funktionen genutzt werden, wie eine Datei (abgesehen natürlich von so > Dingen wie lseek()). Richtig. SysV-IPC ist aber ohnehin ein Sonderfall, das sind ja keine Geräte, sondern Kernelfunktionen wie reservierte Speicherbereiche, Message Queues, ...
Sheeva P. schrieb: >> Netzwerk-Geräte (wie z.B. eth0) jedoch lustigerweise nicht. > > ... mehr. Bei frühen Linux-Kernels war das anders, und unter SunOS / > Solaris auch. SunOS würde mich wundern, denn das war letzlich eine kommerzielle Variante von 4.2BSD, dem System, das das gesamte Socket-Interface überhaupt erstmal ins Leben gerufen hat. > Unter moderneren Linux-Kernels findet man die Geräte in > der Datei /proc/net/dev Ist hier leer. > und die Schnettstillen im Verzeichnis > /sys/class/net/, IIRC. Da steht aller Firlefanz and Informationen drin, aber mit Gerätedateien (im Sinne von: öffne das, und dann hast du deinen Socket-Descriptor) hat das nichts zu tun. > Richtig. SysV-IPC ist aber ohnehin ein Sonderfall, das sind ja keine > Geräte, sondern Kernelfunktionen wie reservierte Speicherbereiche, > Message Queues, ... Ja, völlig an allen anderen Interfaces vorbei, andere Rechte, andere Informationen, anderes Verhalten, anderer Namensraum.
Sheeva P. schrieb: > Rolf M. schrieb: >> Sheeva P. schrieb: >>> Das ist unter UNIX-artigen Betriebssystemen, wie Linux eines ist, >>> gleich. Der Merksatz ist, daß unter UNIX alles eine Datei ist. Jedes >>> Gerät, jeder Endpunkt eines Netzwerk-Socket, schlicht: alles. >> >> Netzwerk-Geräte (wie z.B. eth0) jedoch lustigerweise nicht. > > ... mehr. Bei frühen Linux-Kernels war das anders, und unter SunOS / > Solaris auch. Unter moderneren Linux-Kernels findet man die Geräte in > der Datei /proc/net/dev und die Schnettstillen im Verzeichnis > /sys/class/net/, IIRC. In /proc/net/dev finde ich nur Informationen darüber, welche es gibt und ein paar Statistiken darüber. Unter /sys/class/net befindet sich eine ganze Reihe virtueller Dateien im /proc-Stil, aber kein "Ethernet-device". Und mit den Netzwer-Konfigurationstools gibt man auch nur sowas wie eth0 und nicht einen Dateisystempfad wie /dev/eth0 an, weil die Geräte in einem ganz anderen Namensraum sind. > SysV-IPC ist aber ohnehin ein Sonderfall, das sind ja keine > Geräte, sondern Kernelfunktionen wie reservierte Speicherbereiche, > Message Queues, ... Die könnte man aber natürlich trotzdem über das Filesystem abbilden. Es gibt ja auch named pipes, mmap u.s.w., die zeigen wie's geht.
Jörg W. schrieb: > Sheeva P. schrieb: >> Unter moderneren Linux-Kernels findet man die Geräte in >> der Datei /proc/net/dev > > Ist hier leer. Tja, wenn man das bewußt abschaltet... >> und die Schnettstillen im Verzeichnis >> /sys/class/net/, IIRC. > > Da steht aller Firlefanz and Informationen drin, aber mit Gerätedateien > (im Sinne von: öffne das, und dann hast du deinen Socket-Descriptor) hat > das nichts zu tun. Das wäre auch ziemlich bescheuert, oder? So ein Netzwerkgerät steht ja nur für ein Gerät und kann mit mehreren Sockets gleichzeitig benutzt werden. >> Richtig. SysV-IPC ist aber ohnehin ein Sonderfall, das sind ja keine >> Geräte, sondern Kernelfunktionen wie reservierte Speicherbereiche, >> Message Queues, ... > > Ja, völlig an allen anderen Interfaces vorbei, andere Rechte, andere > Informationen, anderes Verhalten, anderer Namensraum. Andere Funktion. Interprozeßkommunikation (dafür steht das "IPC", nicht wahr?) ist eine Sammlung von Kernelfunktionen, kein Gerät.
Sheeva P. schrieb: >>> Unter moderneren Linux-Kernels findet man die Geräte in >>> der Datei /proc/net/dev >> >> Ist hier leer. > > Tja, wenn man das bewußt abschaltet... Warum unterstellst du mir das? Es ist einfach mal leer, ich habe da nichts zu- oder abgeschaltet. Nicht, dass ich das da irgendwie brauchen würde. >> Ja, völlig an allen anderen Interfaces vorbei, andere Rechte, andere >> Informationen, anderes Verhalten, anderer Namensraum. > > Andere Funktion. Interprozeßkommunikation (dafür steht das "IPC", nicht > wahr?) ist eine Sammlung von Kernelfunktionen, kein Gerät. Interprozesskommunikation, richtig gemacht: * sockets * mmap * pipe SYSVIPC musste halt nur irgendwie alles anders machen.
Jörg W. schrieb: > Sheeva P. schrieb: >>>> Unter moderneren Linux-Kernels findet man die Geräte in >>>> der Datei /proc/net/dev >>> Ist hier leer. >> Tja, wenn man das bewußt abschaltet... > > Warum unterstellst du mir das? > Es ist einfach mal leer, ich habe da nichts zu- oder abgeschaltet. > Nicht, dass ich das da irgendwie brauchen würde. Darf ich fragen, was für ein Linux das ist und ob Du einen selbstgebackenen Kernel benutzt? Mir ist nämlich kein Distributionskernel bekannt, der das deaktiviert hat, und ansonsten sollte die ganze Datei nicht vorhanden sein... >>> Ja, völlig an allen anderen Interfaces vorbei, andere Rechte, andere >>> Informationen, anderes Verhalten, anderer Namensraum. >> >> Andere Funktion. Interprozeßkommunikation (dafür steht das "IPC", nicht >> wahr?) ist eine Sammlung von Kernelfunktionen, kein Gerät. > > Interprozesskommunikation, richtig gemacht: > > * sockets > * mmap > * pipe > > SYSVIPC musste halt nur irgendwie alles anders machen. Oh... und Named Sockets, Unix Domain Sockets, Signale, Mmap-Dateien, und Named Pipes werden unter anderen UNIXen als Dateien angelegt, gar als Nodes in /dev? Äh, welches UNIX macht das so? Ist Shared Memory eine Datei? Was ist mit Semaphores? Aber selbst wenn es so wäre: ist SysV-IPC nicht ein POSIX-Standard, und Du wirfst Linux gerade vor, sich an die einschlägigen Standards zu halten? :-)
Sheeva P. schrieb: >> Warum unterstellst du mir das? >> Es ist einfach mal leer, ich habe da nichts zu- oder abgeschaltet. >> Nicht, dass ich das da irgendwie brauchen würde. > > Darf ich fragen, was für ein Linux das ist und ob Du einen > selbstgebackenen Kernel benutzt? Normales Ubuntu. Aber ich hatte dich falsch verstanden, ich dachte, das soll ein Verzeichnis sein. /proc/net/dev selbst existiert natürlich, aber das ist doch weiter nichts als eine andere Art von "netstat", was man da auslesen kann. Mit einer Gerätedatei (die hatte ich nach deiner Beschreibung da vermutet) hat das herzlich wenig zu tun. >> Interprozesskommunikation, richtig gemacht: >> >> sockets >> mmap >> pipe >> >> SYSVIPC musste halt nur irgendwie alles anders machen. > > Oh... und Named Sockets, Unix Domain Sockets, Signale, Mmap-Dateien, und > Named Pipes werden unter anderen UNIXen als Dateien angelegt, gar als > Nodes in /dev? Keine Nodes in /dev, aber es sind alles Dateidescriptoren im Prozess, so wie ein geöffneter Socket auch. Und ja, man kann auch Dateien mmappen (und sie so als shared memory zwischen nicht miteinander verwandten Prozessen benutzen), und named pipes haben einen Namen im Dateisystem. Daher heißen sie ja so. > Äh, welches UNIX macht das so? Ist Shared Memory eine > Datei? Was ist mit Semaphores? Kann man auch über Pipes machen. > Aber selbst wenn es so wäre: ist SysV-IPC > nicht ein POSIX-Standard, Weiß ich nicht. Kann sein. Posix erfindet ja nichts selbst, sondern standardisiert, was es gibt. Wäre dann auch noch die Frage, inwiefern er verpflichtend oder nur optional ist. > und Du wirfst Linux gerade vor, sich an die > einschlägigen Standards zu halten? :-) Komm mal wieder runter. Ich habe Linux gar nichts vorgeworfen, ich habe lediglich SYSVIPC als ein miserables API bezeichnet, welches völlig aus er (Unix-)Reihe tanzt. Das FreeBSD hier hat das Zeug auch implementiert, ja. Das macht aber das API nicht besser.
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.