Forum: PC-Programmierung Portbenützung (Rechte) unter Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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
von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von tuxxi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf E. schrieb:
> Kann mir da jemand weiterhelfen?

http://www.tuxhausen.de/kurs_inhalt.html

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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.

von tuxxi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ε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

von tuxxi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
für /dev/tty... reicht aber die Gruppe dialout

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ε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.

von Εrnst B. (ernst)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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.

von tuxxi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
mach mal nach einem Reboot folgendes im Terminal:

ls -l /dev/tty*

und stelle das Ergebnis hier ein.

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jack V. (jackv)


Bewertung
0 lesenswert
nicht lesenswert
Du hast dich danach komplett aus- und wieder eingeloggt? Vorher werden 
Änderungen der Gruppenzugehörigkeit nicht wirksam. lp würde ich 
weglassen, btw.

von tuxxi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
probier mal das:

sudo usermod -aG dialout rolf

dann abmelden und wieder anmelden und dann

groups

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.)

von Jack V. (jackv)


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Rolf E. (rolf-56)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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“.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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! ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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. :-)

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
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()).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Le X. (lex_91)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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, ...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
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? :-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.