Programmieren unter Linux
Uli Laube
Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
Linux.
Ich habe mich durch das LDP gelesen, musste aber festellen das die
Informationen die ich suche nicht dabei sind. Das LPG und KHG Buch des
LDP sind zwar ein guter Ansatz, aber es bedarf noch einiger Anstrengung
um bis man damit wirklich arbeiten kann.
Auch die diversen FAQ und HOWTOS geben kaum Auskunft zur Programmierung
unter Linux.
Mir fehlen vor allem Angaben zu folgenden Bereichen:
Wie wird der ProtectMode unter Linux eingesetzt?
Wie bedeutet hier nicht das was in
/usr/src/linux/arch/i386/kernel/head.S steht,
sondern generelle Angaben, zu den verwendeten ProtectedMode Varianten
und Features die genutzt werden. Auch wie die verschiedenen
PM-Erweiterungen der Intel CPUs genutzt werden.
User mode vs. Kernel mode
Was ist das?
Wie ist er realisiert?
Wie kommt ein Programm in den einen oder anderen mode?
Was bedeutet es für mein Programm wenn es in dem einem oder anderem
läuft?
physikalisches memory layout
Wie sieht der Speicher unter Linux aus?
Welche Bereiche gibt es?
Wie werden sie eingesetzt?
Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
logisches memory layout
wie sieht der speicher vor dem laden eines programms aus?
wie danach? (ja, ich weiss das nicht alles geladen wird)
wird das program segmentiert?
wie sieht der speicher für das programm aus?
wo liegt der stack?
ELF binary
Wie ist ein ELF binary ausgebaut?
Wie wird es geladen?
Wohin?
Hardware unter Linux
Kann ein Programm direkt auf die I/O-Ports zugreifen?
Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
(Linear Frame Buffer) ?
Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
Programme verhindert? (Semaphore's)
Helfen würde mir auch ein Hinweis wo ich solche Informationen bekommen
kann.
Es gibt einige Bücher, kann mir da jemand eines empfehlen?
Ich suche quasi ein "PC intern" (Data Becker) für Linux, eine Mischung
aus Einführung und Referenz mit Sourcecode-Beispielen.
Was das PC intern für Hardware und DOS-Programmierung ist, ist "der
Petzold"
für Win95-Programmierung. Gibt es sowas auch für X?
Linux - Kernelprogrammierung
4th Edition 1997 AWL
504p. DEM79.90 ISBN3-8273-1144-6
Anwendungen entwickeln unter Linux
1st. Edition 1998 AWL
580p DEM89.90 ISBN3-8273-1449-6
Linux - Wegweiser zur Programmierung & Entwicklung
1st. Edition 1997 O'Reilly
580p DEM59.00 ISBN3-930673-77-0
Programmieren unter Linux
AWL
500p DEM79.90 ISBN3-89319-8717
Programmieren mit GNU Software
O'Reilly
283p+CD DEM79.00 ISBN3-930673-32-0
Programmieren in der UNIX-Umgebung
AWL
804p DEM99.90 ISBN3-89319-814-8
POSIX Programer's Guide
1st Edition 1991 O'Reilly
640p $34.95 ISBN0-937175-73-0
Porting Unix Software
1st Edition 1995 O'Reilly
538p $29.95 ISBN1-56592-126-7
Ach, eins noch. Ja ich habe alle dise READMEs und sonstigen kleinen
Datei gelesen die da so über das ganze Dateisystem verteilt sind. Das
was da unter /usr/src/linux/Documentation zu finden ist, ist es meiner
Meinung nach nicht Wert Dokumentation genannt zu werden.
Und bitte, den Hinweis, das der Sourcecode ja dabei ist, und man dort ja
nachlesen könnte wie die Dinge funktionieren, empfinde ich als
Frechheit. Ich habe nicht die Zeit und die Lust mich in fremden
Sourcecode einzuarbeiten.
Vielen Dank
Uli Laube
Lutz Donnerhacke
>Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
>Linux.
Deine Fragen beziehen sich nicht auf 'Programmieren unter Linux' sondern auf
'Hacking the kernel for my current system'.
Für ersteres suchst Du den Stevens.
Hartmut Niemann
>Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
>Linux.
Was willst Du tun?
>Hardware unter Linux
>Kann ein Programm direkt auf die I/O-Ports zugreifen?
Ja, wenn es mit root-rechten laeuft.
>Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
Ja, ditto. Aber es sollte es bleiben lassen.
>Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
>(Linear Frame Buffer) ?
Ja. Aber wenn es einen Konsolen-Umschaltvorgang nicht mitbekommt,
dann rappelts im Karton.
>Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
>Programme verhindert? (Semaphore's)
Zugriff worauf?
>Helfen wuerde mir auch ein Hinweis wo ich solche Informationen bekommen
>kann.
Wenn Du Grafik unter linux programmieren willst, dann solltest Du Dir
GGI anschauen - sonst erfindest Du vermutlich das Rad neu.
www.ggi-project.org oder pm an mich.
Hartmut.
>Ach, eins noch. Ja ich habe alle dise READMEs und sonstigen kleinen
>Datei gelesen die da so ueber das ganze Dateisystem verteilt sind. Das
>was da unter /usr/src/linux/Documentation zu finden ist, ist es meiner
>Meinung nach nicht Wert Dokumentation genannt zu werden.
>Und bitte, den Hinweis, das der Sourcecode ja dabei ist, und man dort ja
>nachlesen koennte wie die Dinge funktionieren, empfinde ich als
>Frechheit. Ich habe nicht die Zeit und die Lust mich in fremden
>Sourcecode einzuarbeiten.
Wenn Du nicht sagst, wo Dein Problem ist wird dir keiner helfen koennen.
Wenn Du keinen Source code magst, dann arbeite unter Win95. Dort hast
Du schlechte Doku ohne Quellen. Im Linux-Kern hast Du schlechte Doku
mit Quellen. IMHO ein grosser Fortschritt.
>Vielen Dank
>Uli Laube
Hartmut, der fuer das GGI-Projekt einen Teil der Doku verwaltet und
weiss was das fuer ein '%$&/% Job ist.
--
--
Hartmut Niemann -- niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]
Uli Laube
Hartmut Niemann wrote:
> >Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
> >Linux.
> Was willst Du tun?
Ich möchte mich Informieren. Wenn ich weiss wie es funktioniert
kann ich mich auch entscheiden was ich dann machen möchte, aber im
Moment fehlen mir die Infos dazu.
> Wenn Du Grafik unter linux programmieren willst, dann solltest Du Dir
> GGI anschauen - sonst erfindest Du vermutlich das Rad neu.
> www.ggi-project.org oder pm an mich.
Danke für den Tip
> Wenn Du nicht sagst, wo Dein Problem ist wird dir keiner helfen koennen.
Mein Problem ist, das ich gerne wissen möchte wie einige Teile vom Linux
arbeiten.
Ich habe gestern einen ganzen Tag damit zu gebracht mich durch die
FAQs, HOWTOs, TexInfos, READMEs, .dvi Bücher des LDP, man pages
usw. zu lesen nur um nachher festzustellen das da keine Antworten auf
meine Fragen drin stehen.
Da aber einige Leute ähnlich tiefgreifende Programme schreiben muß es
die Antworten irgenwo gegeben.
> Wenn Du keinen Source code magst, dann arbeite unter Win95.
Ich arbeite unter Win95. Und da gibt es einen großen Vorteil,
es gibt GENAU EINE schlechte Doku, nämlich die zwei SDK Library CDs von M$.
D.h. ich weiss genau wo ich nachsehen muß wenn ich etwas suche, denn
in den 1.2 GB steht vieles drin.
Ein kleinerer Vorteil ist auch noch das die Doku von dem gemacht ist
der den Code geschrieben hat. Was unter Linux leider nicht immer
der Fall ist.
> Dort hast Du schlechte Doku ohne Quellen. Im Linux-Kern hast Du
> schlechte Doku mit Quellen. IMHO ein grosser Fortschritt.
Unter Linux gibt es viel zu viele Stellen an denen man Infos suchen
muß. Teilweise sind die Ergebnisse sogar wiedersprüchlich.
Woher hast du den dein Wissen? Das du mir auf meine Fragen antworten kannst?
Uli Laube
Lutz Donnerhacke
>Mein Problem ist, das ich gerne wissen möchte wie einige Teile vom Linux
>arbeiten.
>Ich habe gestern einen ganzen Tag damit zu gebracht mich durch die
>FAQs, HOWTOs, TexInfos, READMEs, .dvi Bücher des LDP, man pages
>usw. zu lesen nur um nachher festzustellen das da keine Antworten auf
>meine Fragen drin stehen.
>Da aber einige Leute ähnlich tiefgreifende Programme schreiben muß es
>die Antworten irgenwo gegeben.
Das Kernelhacker Buch hast Du erwähnt. Was fehlt da?
>Ich arbeite unter Win95. Und da gibt es einen großen Vorteil,
>es gibt GENAU EINE schlechte Doku, nämlich die zwei SDK Library CDs von M$.
>D.h. ich weiss genau wo ich nachsehen muß wenn ich etwas suche, denn
>in den 1.2 GB steht vieles drin.
>Ein kleinerer Vorteil ist auch noch das die Doku von dem gemacht ist
>der den Code geschrieben hat. Was unter Linux leider nicht immer
>der Fall ist.
find /var/src/linux/ -name '*.c' | xargs grep -il ...
>Unter Linux gibt es viel zu viele Stellen an denen man Infos suchen
>muß. Teilweise sind die Ergebnisse sogar wiedersprüchlich.
Kris sagte mal:
"Die Dokumentation findet sich in den Dateien mit der Endung .c".
Da sich zwischen Erkenntnis, Tippen und Publizieren einer Doku einige
Versionen entwickelt haben, sind diese Dokus notwendig falsch. Mit dem
Handbuch zur Kernelprogrammierung hast Du einen Leitfaden, Dich
durchzufinden.
>Woher hast du den dein Wissen? Das du mir auf meine Fragen antworten kannst?
Lesen und lernen.
Uli Laube
Lutz Donnerhacke wrote:
> Das Kernelhacker Buch hast Du erwähnt. Was fehlt da?
"Most of the information reported here is taken from the source code of Linux
release 1.0."
Da fehlt ein ganzes Jahr in der Entwicklung von Linux.
Das Kapitel mit der Übersicht des Memory Management von Linux ist 17 Seiten
lang/kurz.
Im original Intel System Programming Guide ist die Übersicht 34 Seiten
lang/kurz.
Wie ein ELF binary aussieht. (das elf.pdf hab ich dann bei download.intel.com
gefunden ??)
Wie ein Programm im Speicher angeordnet ist.
Oder zum Beispiel so interessante Fragen wie es mit VBE BIOS PMode-Interface
aufrufen aussieht.
Ich kann nicht verstehen das über das Herz von Linux, von dem so viel abhängt
nur so wenig
brauchbare Infos verfügbar sind.
> find /var/src/linux/ -name '*.c' | xargs grep -il ...
kein Kommentar
> Kris sagte mal:
> "Die Dokumentation findet sich in den Dateien mit der Endung .c".
Bei allem Verständnis für selbstdokumentierenden Code und ähnlichen Ansätzen,
kann und wird es nicht die Aufgabe von SourceCode sein die Dokumentation
zu liefern.
Es wird zum Beispiel nicht erklärt warum etwas so gelöst wurde wie es gelöst
wurde, das es mit einer anderen Lösung diese und jene Probleme gab und das
es deswegen so ist wie es ist. Oder generell das es diese und jene Möglichkeit
gibt das Problem zu lösen.
Außerdem sind .c files nicht einheitlich. Jeder mitwirkende Programmierer
hat seinen Teil anders "gestaltet", was die Verständlichkeit nicht gerade
verbessert.
Es fehlen eben all diese kleinen Dinge die eine Doku ausmachen und sie
von einer Sammlung .c files unterscheiden.
Ich lese ein Doku weil ich etwas nicht kenne, und es kennenlernen will.
Um .c files zu verstehen muß ich schon viel wissen, um sie zu verstehen.
Gruß
Uli Laube
Christian Anzenberger
> Ich brauche Hilfe. <...>
Hello world.
Deine Fragen passen nicht ganz zum Subject. Anscheinend gehen Deine
Präferenzen eher in Richtung Kernel- und Devicetreiber-Programmierung. Dazu
gibt es den schon angesprochenen Kernel Hackers Guide und ein paar Bücher
von O'Reilly und anderen. Da die Entwicklung hier der Dokumentation immer
voraus ist, ist die letzte Instanz bei solchen tiefgreifenden Fragen immer
der Sourcecode, da hilft kein Beten und kein Fluchen.
Wenn Du Dich grundsätzlich für die Architektur eines Unix-ähnlichen
Betriebssystemes interessierst und hier noch keine wesentlichen
Vorkenntnisse hast, ist vielleicht Xinu eine gute Spielwiese. Das Ding ist
viel kleiner und einfacher als Linux und daher leichter zu durchschauen.
Erste Info: http://willow.canberra.edu.au/~chrisc/xinu.html. Es gibt auch
Bücher, die das Ding haarklein erklären. ISBN hab ich irgendwo. Ein
ähnliches Ding ist Minix, da gibt es auch ein Buch dazu. Mit den hier
vermittelten Grundwissen kanst Du Dich dann etwas besser bewaffnet auf den
Linux Source stürzen.
Vielleicht meinst Du aber wirklich "Programmieren unter Linux".
Wenn Du nicht nicht im Kernel selbst herumprogrammierst, gibt es jede Menge
freundlicher Libraries, die Dir eine Schnittstelle zu allem möglichen
herstellen. Über manche gibt es Schränke von Bücheren, über andere gibt es
wirklich nur das, was in Deinen Augen keine Dokumentation ist.
Wenn Du Anwendungen unter Unix-/Linux programmieren willst, dann gibt es
mehr Bücher als Du schleppen kannst. Das beginnt bei grundsätzlichen
Programmiertechniken unter Unix bis zu detaillierten Abhandlungen über sehr
spezielle Techniken. Was sich da eignet hängt von den Vorkenntnissen ab. Am
besten in eine gute Fachbuchhandlung gehen und einen Nachmittag blättern.
Prinzipiell wird Dich alles interessieren, wo Unix draufsteht. Nahezu alles
gilt für Linux genauso. Zusätzlich haben sich unter Linux
Programmierschnittstellen etabliert (wie etwa qt, Gtk und viele andere),
die bei einem kommerziellen Unix nicht dabei sind. Dort ist das Internet
und ein paar mitgelieferte manpages die Quelle allen Wissens. Und halt
wieder der gute alte Source.
Die Moral von der Geschicht:
"So schreibt man ein Linux-Programm" gibt es nicht. Das gibt es bestenfalls
für DOS. Wenn Du Windows-Programme schreibst, brauchst Du auch eine Weile,
bis Du durch die MFC durch bist. Unter Unix/Linux gibt es fünfzig bis
hundermal mal so viel zu wissen.
Du wirst Dich also entscheiden müssen, von welcher Seite Du die Torte
anschneidest.
Have fun. Have success.
Christian.
Joerg Plate
> Ich kann nicht verstehen das über das Herz von Linux, von dem so
> viel abhängt nur so wenig brauchbare Infos verfügbar sind.
Weil man normalerweise die ganzen Informationen nicht braucht.
Der Unterschied zwischen a.out und ELF interessiert micht nicht, das
macht der Compiler. ProtectedMode,BIOS,PCI-Kartenspeicher? Brauche
ich nichts drüber zu wissen. Wie ist der Speicher aufgebaut? Ist auch
egal, es gibt ja "malloc()". Wo liegt der Stack? Auch
uninteressant. SVGA-Register? Es gibt X :-)
Das braucht man nur wenn irgendwelche Treiber schreiben will, aber
für normale Programme?
Was willst Du eigentlich machen?
--
"i'm working on it"
Uli Laube
Joerg Plate wrote:
> Der Unterschied zwischen a.out und ELF interessiert micht nicht, das
> macht der Compiler. ProtectedMode,BIOS,PCI-Kartenspeicher? Brauche
> ich nichts drüber zu wissen. Wie ist der Speicher aufgebaut? Ist auch
> egal, es gibt ja "malloc()". Wo liegt der Stack? Auch
> uninteressant. SVGA-Register? Es gibt X :-)
Dann sag mir wo die Doku zu X zu finden ist. Dann geht die gleiche
Sucherei wieder von vorne los.
> Das braucht man nur wenn irgendwelche Treiber schreiben will, aber
> für normale Programme?
Ach, tatsächlich?
Ein normales Programm stellt doch etwas am Monitor dar oder?
Also muß es ab und zu mal ein paar Pixel einfärben.
Und ich weiss nicht wie du das machen willst ohne ein paar Dinge
über dein System zu wissen.
Bei Bibliotheken von anderen Leuten ist wieder das Problem die
Doku zu bekommen.
> Was willst Du eigentlich machen?
Ich will es einfach nur wissen. Ist das so schwer zu verstehen?
Gruß
Uli Laube
Mirko Dziadzka
>Lutz Donnerhacke wrote:
>> Das Kernelhacker Buch hast Du erwähnt. Was fehlt da?
>"Most of the information reported here is taken from the source code of Linux
>release 1.0."
>
>Da fehlt ein ganzes Jahr in der Entwicklung von Linux.
Wenn du was ueber den Linux-Kernel wissen willst, gibt es ausser der
KHG und dem "Linux-Kernel Programmierung" noch drei andere aktuelle Quellen:
- Alessando Rubini, Linux Device Drivers, O'Reilly, 1998
- Remy Card, ... ,the Linux Kernel book, 1998
- /usr/src/linux/*
>Wie ein ELF binary aussieht. (das elf.pdf hab ich dann bei download.intel.com
>gefunden ??)
Warum soll sich jemand die Muehe machen, den Aufbau einer ELF-Datei
nochmal zu beschreiben, wenn es schon eine Doku gibt. ELF ist keine
Erfindung von Linux.
>Ich kann nicht verstehen das über das Herz von Linux, von dem so viel abhängt
>nur so wenig brauchbare Infos verfügbar sind.
Die Informationen sind da. Nur ueber sehr viele Stellen verteilt.
>> find /var/src/linux/ -name '*.c' | xargs grep -il ...
>kein Kommentar
Wenn du dich fuer solche Internas interessierst, ist es eine sehr gute
Loesung. Ich wuerde allerdings '*.[Sch]' nehmen :-)
>> Kris sagte mal:
>> "Die Dokumentation findet sich in den Dateien mit der Endung .c".
>Bei allem Verständnis für selbstdokumentierenden Code und ähnlichen Ansätzen,
>kann und wird es nicht die Aufgabe von SourceCode sein die Dokumentation
>zu liefern.
Wer braucht die Doku zum Linux-Kernel? User? Nein! Zukuenftige Kernel
Hacker? Die haben 3 Buecher und die KHG um den Ueberblick ueber den
Source-Code zu bekommen. Wenn sie der aktuellen Entwicklung folgen wollen,
das kommen die am Source und an der Lektuere der linux-kernel Mailingliste
nicht vorbei!
>Es wird zum Beispiel nicht erklärt warum etwas so gelöst wurde wie es gelöst
>wurde, das es mit einer anderen Lösung diese und jene Probleme gab und das
>es deswegen so ist wie es ist. Oder generell das es diese und jene Möglichkeit
>gibt das Problem zu lösen.
linux-kernel Mailingliste Lesen - die sollte auch irgendwo archiviert
sein. Da finden die Diskussionen statt und findest du deine Antworten.
Ansonsten - es gibt auf dem Buchmarkt sicher noch Platz fuer ein weiters
Buch zum Linux-Kernel.
>Ich lese ein Doku weil ich etwas nicht kenne, und es kennenlernen will.
>Um .c files zu verstehen muß ich schon viel wissen, um sie zu verstehen.
Fang mit der KHG an. Dann lese das Device Driver Buch und das Kernel
Programmierung Buch. Wenn du dann immer noch mehr wissen willst, lies
den Source oder frage in Mailinglisten/Newsgroups nach.
Mirko
--
++++++++++++ Linux - das beste Textadventure aller Zeiten ++++++++++++
Mirko Dziadzka
>Dann sag mir wo die Doku zu X zu finden ist. Dann geht die gleiche
>Sucherei wieder von vorne los.
Wenn du es kostenlos haben willst wuerde ich bei www.x.org und
www.xfree86.org anfangen zu suchen. Wenn du Geld ausgeben willst geh
zum Buchhaendler deines Vertrauens, geh ans Regal mit den X Buechern
und such dir welche aus. Es gibt mehr als reichlich davon.
>> Das braucht man nur wenn irgendwelche Treiber schreiben will, aber
>> für normale Programme?
>
>Ach, tatsächlich?
>Ein normales Programm stellt doch etwas am Monitor dar oder?
>Also muß es ab und zu mal ein paar Pixel einfärben.
Nehm das Toolkit deiner Wahl. Es gibt ca. 20 davon. Das geht ganz
unten auf X-Ebene los ("Hello World" im Button in 6 Seiten C) geht ueber
Loesungen wie Athena-Widgets, Motif (eine Seite C), Qt, gtk (10 Zeilen C)
und endet bei Toolkits wie Tcl/Tk (2 Zeilen)
Aber dafuer brauchst du *nichts* ueber den Kernel, das Ansteuern der
Graphikkarte, das Memory-Layout oder sonstige Internas zu wissen. "Normale
Programme" sind in der Regel nicht Linux-spezifisch sondern laufen auf
jedem Unix System.
>Bei Bibliotheken von anderen Leuten ist wieder das Problem die
>Doku zu bekommen.
Die wird bei Bibliotheken mitgeliefert. Sonst sind die naemlich unbrauchbar.
>> Was willst Du eigentlich machen?
>Ich will es einfach nur wissen. Ist das so schwer zu verstehen?
Deine Fragen beziehen sich auf ein so breites Gebiet, das du keine
allgemeine Antwort bekommen willst. Deswegen die Frage, was du eigentlich
*konkret* machen willst.
Gerd Knorr
>Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
>Linux.
>Wie wird der ProtectMode unter Linux eingesetzt?
>sondern generelle Angaben, zu den verwendeten ProtectedMode Varianten
>und Features die genutzt werden. Auch wie die verschiedenen
>PM-Erweiterungen der Intel CPUs genutzt werden.
Linux benutzt (auf i486) die Paging MMU. Segmente werden beim booten
einmal initialisiert und dann nie weider angefaßt (Ausnahme: dosemu,
wine, ...).
>User mode vs. Kernel mode
>Was ist das?
Kauf dir ein UNIX-Buch, ist bei Linux nicht anders als bei anderen
Unixen auch.
>physikalisches memory layout
>Wie sieht der Speicher unter Linux aus?
>Welche Bereiche gibt es?
486: 0-3GB user space, 3-4 GB kernel space (lineare Adressen).
Der physikalische Speicher wird komplett in den kernel-Addressraum
eingeblendet (ab 3 GB). Macht 3 GB virtual memory pro Prozeß und
knapp 1 GB verwaltbares RAM.
>Wie werden sie eingesetzt?
>Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
>die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
landet zwischen 0xc00a0000 und 0xc0100000
>Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
Kann bei Bedarf per MMU gemappt werden.
>logisches memory layout
>wie sieht der speicher vor dem laden eines programms aus?
Leer :-)
>wie danach? (ja, ich weiss das nicht alles geladen wird)
Hängt vom Binärformat, dynamischen linker, ... ab.
>wird das program segmentiert?
nein.
>ELF binary
>Wie ist ein ELF binary ausgebaut?
>Wie wird es geladen?
>Wohin?
Keine Ahnung.
>Hardware unter Linux
>Kann ein Programm direkt auf die I/O-Ports zugreifen?
>Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
>Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
>(Linear Frame Buffer) ?
Normalerweise nicht. Mit root-rechten kann man sich manche Dinge
freischalten.
>Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
>Programme verhindert? (Semaphore's)
Ja.
>Ach, eins noch. Ja ich habe alle dise READMEs und sonstigen kleinen
>Datei gelesen die da so über das ganze Dateisystem verteilt sind. Das
>was da unter /usr/src/linux/Documentation zu finden ist, ist es meiner
>Meinung nach nicht Wert Dokumentation genannt zu werden.
>Und bitte, den Hinweis, das der Sourcecode ja dabei ist, und man dort ja
>nachlesen könnte wie die Dinge funktionieren, empfinde ich als
>Frechheit. Ich habe nicht die Zeit und die Lust mich in fremden
>Sourcecode einzuarbeiten.
Du wirst Dir die Zeit für die Einarbeitung nehmen müssen. Weniger für
spezielle Linux-Dinge und kernel-source lesen, mehr für UNIX allgemein
und die dahinterstehenden Grundideen und Konzepte. Ansonsten kommst du
nicht weit, das verspreche ich Dir.
Viele von den Dingen, die du oben gefragt hast, brauchst du für
Programmierung gar nicht. Definitiv nicht für Anwenderprogramme.
Vielleicht für Hardware- und Treiberprogrammierung. Aber selbst
dafür eigentlich nicht.
Gerd
--
New mail address: Gerd Knorr <kra...@goldbach.in-berlin.de>
Christoph Kliemt
> Hi!
>
> Lutz Donnerhacke wrote:
>
> > Das Kernelhacker Buch hast Du erwähnt. Was fehlt da?
>
> "Most of the information reported here is taken from the source code of Linux
> release 1.0."
>
> Da fehlt ein ganzes Jahr in der Entwicklung von Linux.
Mehr... Ich erinnere mich dunkel dass der 2.0 vor mehr als einem Jahr
rauskam... zwei oder drei .. ?!
>
> Das Kapitel mit der Übersicht des Memory Management von Linux ist 17 Seiten
> lang/kurz.
> Im original Intel System Programming Guide ist die Übersicht 34 Seiten
> lang/kurz.
Fein. Intel is eh besser... ;)
>
> Wie ein ELF binary aussieht. (das elf.pdf hab ich dann bei download.intel.com
> gefunden ??)
> Wie ein Programm im Speicher angeordnet ist.
> Oder zum Beispiel so interessante Fragen wie es mit VBE BIOS PMode-Interface
> aufrufen aussieht.
Eine grundsätzliche Frage: Was willst Du ? Kernel hacken oder eigene
Programme entwickeln ? Irgendwie quillt aus Deinen Statements DOS...
>
> Ich kann nicht verstehen das über das Herz von Linux, von dem so viel abhängt
> nur so wenig
> brauchbare Infos verfügbar sind.
Schick mir bei Gelegenheit mal das Analogon für eNTe...
<philosophier>
hmm... brauchbare Infos... was ist ein brauchbares
Info... Quelltext... aber man weiss ja nicht wie das gemeint
war... kernel eMailliste mitlesen... selbst mental
nachvollziehen... oder am besten selbst neu schreiben... ;)
</philosophier>
>
> > find /var/src/linux/ -name '*.c' | xargs grep -il ...
>
> kein Kommentar
nein ? schade...
> > Kris sagte mal:
> > "Die Dokumentation findet sich in den Dateien mit der Endung .c".
>
> Bei allem Verständnis für selbstdokumentierenden Code und ähnlichen Ansätzen,
> kann und wird es nicht die Aufgabe von SourceCode sein die Dokumentation
> zu liefern.
<ack>
> Es wird zum Beispiel nicht erklärt warum etwas so gelöst wurde wie
> es gelöst wurde, das es mit einer anderen Lösung diese und jene
> Probleme gab und das es deswegen so ist wie es ist. Oder generell
> das es diese und jene Möglichkeit gibt das Problem zu lösen.
Sag mal: Was willst Du eigentlich ? Beschützende Werkstätte für
eNTengenervte oder was ? Wenn Dir die Doku nicht passt, dann schreib
sie selbst ! Soweit ich weiss gibt "Linux Inc" nur einen geringen Teil
des Etats für Promo,Doku und so aus...
> Außerdem sind .c files nicht einheitlich. Jeder mitwirkende Programmierer
> hat seinen Teil anders "gestaltet", was die Verständlichkeit nicht gerade
> verbessert.
shit happens...
> Es fehlen eben all diese kleinen Dinge die eine Doku ausmachen und sie
> von einer Sammlung .c files unterscheiden.
brilliant beobachtet...
> Ich lese ein Doku weil ich etwas nicht kenne, und es kennenlernen
> will. Um .c files zu verstehen muß ich schon viel wissen, um sie zu
> verstehen.
Tip : Beschwer Dich beim Hersteller !
MfG Christoph
Oliver Jung
Uli Laube <uli....@wiesbaden.netsurf.de> writes:
[über die Doku zu Windows]
> Ein kleinerer Vorteil ist auch noch das die Doku von dem gemacht ist
> der den Code geschrieben hat. Was unter Linux leider nicht immer
> der Fall ist.
Das glaubst Du doch wohl selber nicht, oder ?
Weisst Du wieviele Leute alleine in Seattle an den Winxx-"Kernels"
arbeiten ? Ausserdem haben die eine ganz eigene Abteilung für Doku
usw...
Olli (der mal für die Firma gearbeitet hat, die die M$-Doku ins
Deutsche übersetzt...)
--
Oliver Jung o...@badboy.ruhr.de
"Where did they teach you to talk like this ?"
"In some Panama-City-Sailors-Wanna-Hump-Hump-Bar ?"
( Melvin Udall, As Good As It Gets )
Joerg Plate
> Ein normales Programm stellt doch etwas am Monitor dar oder? Also
> muß es ab und zu mal ein paar Pixel einfärben.
Ein Programm das plötzlich am X-Server vorbei "ein paar Pixel" einfärbt
fliegt aber sehr schnell von der Platte...
>> Was willst Du eigentlich machen?
> Ich will es einfach nur wissen. Ist das so schwer zu verstehen?
Ja. Wenn Du "alles" wissen willst dann bis Du für den Rest Deines
Lebens mit Lesen beschäftigt und kommst nicht dazu ein Programm zu
schreiben.
Ansonsten schliesse ich mich Mirko an.
Christian Moench
> [...]
> Ich will es einfach nur wissen. Ist das so schwer zu verstehen?
>
>
> Uli Laube
Eine gute Einführung in Unix Konzepte und deren Realisierung im
Linux Kernel bildet IMHO 'The Linux Kernel' von David A. Rusling.
Findet sich im LDP, z.B. unter:
http://www.fokus.gmd.de/linux/linux-doc-ldp.html
Gruß Christian
--
Christian Mönch
Jochim Selzer
> Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
> Linux.
Probier mal:
Maurice J. Bach
UNIX : wie funktioniert das Betriebssystem? / Maurice J. Bach. Die dt.
Uebers. bes. Systemanalytiker R. J. Sauerer. - Muenchen [u.a.] : Hanser
[u.a.], 1991. - XIII, 424 S. : graph. Darst. -- Originaltitel: The
design of the UNIX operating system <dt.>.
HTH Jochim
Klaus-Georg Adams
Uli Laube <uli....@wiesbaden.netsurf.de> writes:
>
> Hallo!
Hallo zurück.
> Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
> Linux.
>
> Ich habe mich durch das LDP gelesen, musste aber festellen das die
> Informationen die ich suche nicht dabei sind. Das LPG und KHG Buch des
> LDP sind zwar ein guter Ansatz, aber es bedarf noch einiger Anstrengung
> um bis man damit wirklich arbeiten kann.
> Auch die diversen FAQ und HOWTOS geben kaum Auskunft zur Programmierung
> unter Linux.
>
> Mir fehlen vor allem Angaben zu folgenden Bereichen:
>
> Wie wird der ProtectMode unter Linux eingesetzt?
> Wie bedeutet hier nicht das was in
> /usr/src/linux/arch/i386/kernel/head.S steht,
> sondern generelle Angaben, zu den verwendeten ProtectedMode Varianten
> und Features die genutzt werden. Auch wie die verschiedenen
> PM-Erweiterungen der Intel CPUs genutzt werden.
>
> User mode vs. Kernel mode
> Was ist das?
> Wie ist er realisiert?
> Wie kommt ein Programm in den einen oder anderen mode?
> Was bedeutet es für mein Programm wenn es in dem einem oder anderem
> läuft?
Ich glaube wenn du noch nie unter Linux programmiert hast, dann willst
du das alles nicht wissen (denn all das macht der Kernel transparent
für alle Programme). Alles was ein Programm tut, ist die Interfaces zu
nutzen, die in der libc (oder auch libpthread) zur Verfügung gestellt
werden.
Dabei schaltet dein Programm automatisch in den Kernel-mode (nämlich
mit jedem syscall, den es absetzt). Der Programmierer kümmert sich
nicht darum.
>
> physikalisches memory layout
> Wie sieht der Speicher unter Linux aus?
Flach und gross :-)
> Welche Bereiche gibt es?
> Wie werden sie eingesetzt?
malloc() bzw. new.
> Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
> die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
> Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
Interessiert nicht, da der Betriebssystemkern alles managed. Wenn du
wirklich eine neue Karte ansprechen willst, dann mußt du einen Treiber
schreiben, der in den Kernel gelinkt wird (statisch, beim
neuübersetzen der Kernels, oder dynmanisch via insmod). Aber das als
erstes Progammierprojekt unter Linux zu versuchen... Keine gute Idee IMNSHO.
> logisches memory layout
> wie sieht der speicher vor dem laden eines programms aus?
> wie danach? (ja, ich weiss das nicht alles geladen wird)
> wird das program segmentiert?
nein. Speicherlayout etc. hat ein Programm normalerweise nicht zu
interessieren.
> wie sieht der speicher für das programm aus?
> wo liegt der stack?
Wer will das wissen?
> ELF binary
> Wie ist ein ELF binary ausgebaut?
> Wie wird es geladen?
> Wohin?
Wenn dich die Details interessieren, dann hol dir die Quellen von gdb,
dem Debugger. Dort gibt es eine Bibliothek namens bfd mit Doku. Sie
enthält alles über die Executableformate die gdb unterstützt, und da
ist auch elf dabei.
> Hardware unter Linux
> Kann ein Programm direkt auf die I/O-Ports zugreifen?
Nein, das macht nur der Kernel. Ein Programm, das auf I/O Ports
zugreift ist Broken-By-Design (Ausnahmen bestätigen die Regel).
Alle Devices, die der Kernel kennt, werden als Devicefiles abgebildet
unter /dev. Die serielle Schnittstelle z.B. heisst /dev/ttys0 ff. Sie
wird benutzt wie jede andere Datei auch (open(), read(), write()),
aber für die Specials (Baud-rate etc.) gibt es noch ein anderes
Interface (termios()). Änliches gilt für alle andere Hardware.
> Kann ein Programm direkt auf Memory Mapped Register (SVGA)
> zugreifen?
Nein. Dazu benutzt man X.
> Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
> (Linear Frame Buffer) ?
Dito. Dazu benutzt man X.
> Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
> Programme verhindert? (Semaphore's)
man flock(2), man ipc(2)
> Helfen würde mir auch ein Hinweis wo ich solche Informationen bekommen
> kann.
man 2 intro, man 3 intro
>
> Es gibt einige Bücher, kann mir da jemand eines empfehlen?
> Ich suche quasi ein "PC intern" (Data Becker) für Linux, eine Mischung
> aus Einführung und Referenz mit Sourcecode-Beispielen.
> Was das PC intern für Hardware und DOS-Programmierung ist, ist "der
> Petzold"
> für Win95-Programmierung. Gibt es sowas auch für X?
>
Wenn du ein normales Programm schreiben willst, dann nimm den Stevens
> Programmieren in der UNIX-Umgebung
> AWL
> 804p DEM99.90 ISBN3-89319-814-8
Wenn du Programme mit GUI schreiben willst, dann besorge dir die
Quellen von Xfree86, dort findest du unterhalb von xc/doc/hardcopy
ca. 10000 Seiten mit mehr als du wirklich wissen willst. Oder du
kaufst das ganze in einer veralteten, aber etwas lesbareren Version
von O'Reilly (zu empfehlen hier: Volume Four, X Toolkit Intrinsics
Programming Manual).
Nur wenn du tatsächlich Schweinereien mit einer speziellen Hardware
machen willst, dann mußt du dich um einen Kerneltreiber kümmern. Ein
guter Startpunkt (zwar völlig veraltet, aber die Prinzipien stimmen
noch, für die aktuelle Version: RTFS) sind die Files tutorial.doc und
drivers.doc, die z.B. auf tsx11 unter ALPHA/drv_guide stehen.
--
-------------------------------------------------------------------------
Klaus-Georg Adams Email: Klaus-Ge...@chemie.uni-karlsruhe.de
Institut f. Anorg. Chemie, Lehrstuhl II Tel: 49(0)721 608 3485
Universität Karlsruhe, D-76128 Karlsruhe
-------------------------------------------------------------------------
ku...@lpr.e-technik.tu-muenchen.de.nospam
: Wie wird der ProtectMode unter Linux eingesetzt?
Immer!
: User mode vs. Kernel mode
: Was ist das?
Im User-Mode hat man z.B. keinen Zugriff auf HW-Register
(Nur der Kernel darf auf geräte zugreifen. ausnahme: programme
mit root-rechten)
: Wie ist er realisiert?
Ich weiß ja nicht wie der intel-mist realisiert ist, aber bei
Motorola gibt es die unterscheidung Supervisor/User-Mode für
den prozessor ...
: Wie kommt ein Programm in den einen oder anderen mode?
Durch System-Calls und Interrupts
: Was bedeutet es für mein Programm wenn es in dem einem oder anderem
: läuft?
Dein Programm läuft immer im User-Mode!
Außnahme: Dein programm ist ein kernel-modul (z.B. RT-Linux)
: physikalisches memory layout
: Wie sieht der Speicher unter Linux aus?
Jedem Programm (im User-Mode) steht sein privater- daten
und evtl shared code-speicher zur verfügung, der bei logisch
0 abfängt (AFAIR), also mit MMU
Der Kernel greift AFAIR immer auf den physikalische Bereich zu
(also ohne MMU, d.h. so wie unter DOS)
: Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
: die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
: Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
Der Kernel sollte alle sehen können - Programme im User-Space
natürlich nicht.
: logisches memory layout
: wie sieht der speicher vor dem laden eines programms aus?
?? leer ??
: wie danach? (ja, ich weiss das nicht alles geladen wird)
Beginnt bei 0
: wird das program segmentiert?
Code, Daten und Stack
: wie sieht der speicher für das programm aus?
: wo liegt der stack?
: ELF binary
: Wie ist ein ELF binary ausgebaut?
Ist das Wichtig?
: Hardware unter Linux
: Kann ein Programm direkt auf die I/O-Ports zugreifen?
Nur als Kernelmodul oder als User-Programm mit root-rechten
: Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
nur im kernel-modud.
: Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
: (Linear Frame Buffer) ?
nur im kernel-modus.
: Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
: Programme verhindert? (Semaphore's)
ja, nennt sich "device-driver"
: Helfen würde mir auch ein Hinweis wo ich solche Informationen bekommen
: kann.
HOW-TOs lesen (z.b. mini-io-port-programming-howto)
: Was das PC intern für Hardware und DOS-Programmierung ist, ist "der
: Petzold"
: für Win95-Programmierung. Gibt es sowas auch für X?
Tonnenweise ...
: Linux - Kernelprogrammierung
Wenn Du Geräte-Treiber für eigene Hardware entwickeln möchtest ...
Wenn Du aber nur ein Fenster mit Buttons und Grafik haben
möchtest, dann schau dir mal lieber GTK+(GTK--) und Qt/KDE an.
: Und bitte, den Hinweis, das der Sourcecode ja dabei ist, und man dort ja
: nachlesen könnte wie die Dinge funktionieren, empfinde ich als
: Frechheit.
Ich nicht (mehr). Doku kann mehrdeutig sein - sourcecode ist eindeutig!
Wenn was unklar ist, sieht man einfach nach!
Außerdem sind mir Programm-beispiele 1000 mal lieber, als
Doku.
--
-------------------------------------------------------------------
| Bernhard Kuhn (kuhn[at]lpr.ei.tum.de) O|||OO||OO| |
| Laboratory for Process Control and Real-Time Systems O|||O|O|O|O |
| Technische Universität München Tel.+49-89-289-23732 O|||OO||OO| |
| 80290 München, Germany Room 3944 Fax -23555 OOO|O|||O|O |
--------------------------------------------------------------------
Axel Schwenke
schrieb Uli Laube <uli....@wiesbaden.netsurf.de>:
>Wie wird der ProtectMode unter Linux eingesetzt?
Der wird nicht eingesetzt. Linux schaltet beim Booten in den
PM und bleibt da.
>und Features die genutzt werden. Auch wie die verschiedenen
>PM-Erweiterungen der Intel CPUs genutzt werden.
Von dir gar nicht. Privilegierte Anweisungen sind nur im
Kernel Mode erlaubt.
>User mode vs. Kernel mode
>Was ist das?
Kernel Mode ist PM Ring 0.
>Wie ist er realisiert?
>Wie kommt ein Programm in den einen oder anderen mode?
Gar nicht. Der Kernel (+Devicetreiber +Module) läuft im Kernel-
Mode. Jedes Programm im Usermode. Wenn dein Programm einen
Systemruf macht (etwa open(2)), arbeitet der Kernel mal für dich
- was nicht heißt daß dein Programm in Kernelmode wäre.
>physikalisches memory layout
>Wie sieht der Speicher unter Linux aus?
>Welche Bereiche gibt es?
>Wie werden sie eingesetzt?
Gibt es nicht für Userspace-Programme.
>Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
>die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
>Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
Wird irgendwo in den Kernelbereich 3GB-4GB gemappt und i.d.R.
nicht mehr angefaßt.
>logisches memory layout
>wie sieht der speicher vor dem laden eines programms aus?
3GB nicht gemappter Speicher.
>wie danach? (ja, ich weiss das nicht alles geladen wird)
Eine Page mit dem Textsegment von main(). X Pages mit statischen
Daten, wo sie der Linker hingelegt hat. Y Pages shared Libraries,
wo sie ld.so hingelegt hat.
>wird das program segmentiert?
Nein.
>wo liegt der stack?
Bei 3GB. Dem Ende des Prozeßspeicherraums.
>ELF binary
>Wie ist ein ELF binary ausgebaut?
elf-FAQ lesen.
>Wie wird es geladen?
less /usr/src/linux/fs/binfmt_elf.c
>Wohin?
In seinen eigenen privaten Adreßraum.
>Hardware unter Linux
>Kann ein Programm direkt auf die I/O-Ports zugreifen?
Nur mit root-Rechten.
>Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
dito
>Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
>(Linear Frame Buffer) ?
dito
>Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
>Programme verhindert? (Semaphore's)
Nur wenn du nicht direkt zugreifst.
>Ach, eins noch. Ja ich habe alle dise READMEs und sonstigen kleinen
>Datei gelesen die da so über das ganze Dateisystem verteilt sind.
Haha. Guter Witz! Du mußt dieser Methusalem sein, oder?
Tja Uli, wenn du *für* Linux (eigentlich UNIX) programmieren willst,
solltest du die ganzen schlechten DOS-Manieren (direkter Hardware-
zugriff, Speicherlayout, etc.) ablegen. Alles was du unter Linux
machen kannst, kannst du nur unter Kooperation des Kernels.
D.h. dir bleiben Systemrufe (ls /usr/man/man2),
die C-Lib (ls /usr/man/man3) sowie beliebig viele weitere Libraries
für die merkwürdigsten Dinge. Dazu gehören die X-Lib für Netzwerk-
transparenten, maschinenunabhängigen Zugriff auf Grafik-Bildschirme
(ca. A4x1m Dokumentation) und darauf aufbauende Toolkits.
Ferner (nur für Linux) SVGAlib und (bald?) GGI für mehr oder weniger
direkten Framebuffer-Zugriff.
Deiner Vorstellung eines API kommt vermutlich das GameSDK auf
<http://sunsite.auc.dk/penguinplay/> am nächsten. Aber sei gewarnt -
für Grafik-Demos a'la "Second Reality" oder "DOOM" artige Spiele
bleibt dir unter Linux nur ein portabler Weg - X. Und das ist
eigentlich immer zu langsam.
AxEL
--
|-----------------------------------------------------------------------|
| Dipl-Math. Axel Schwenke, HTW Mittweida ............ schw...@htwm.de |
| everyday a joke ......... http://datamill.mpi.htwm.de:4711/jotd.shtml |
|____________ In A World Without Fences Who Needs Gates? _____________|
Christian Perle
: physikalisches memory layout
: Wie sieht der Speicher unter Linux aus?
: Welche Bereiche gibt es?
: Wie werden sie eingesetzt?
: Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
: die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
: Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
: Hardware unter Linux
: Kann ein Programm direkt auf die I/O-Ports zugreifen?
: Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
: Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
: (Linear Frame Buffer) ?
: Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
: Programme verhindert? (Semaphore's)
Mit solchen Fragen muss man sich doch nur bei der DOS-Programmierung
auseinandersetzen. Unter Linux laeuft jedes Programm in einem eigenen,
virtuellen Speicher. Physikalische Adressen interessieren da gar nicht.
Direkter Zugriff auf Hardwarekomponenten ist bei einem Multitasking-OS
eine schlechte Idee. Darum machen die Programme diese Zugriffe ueber
den Kernel, also die Device-Files.
Geht es Dir bei Deinen Fragen um Programmierung von Anwendungen oder um
Kernel-Interna?
Fuer die Programmierung unter X suchst Du Dir am besten erstmal ein
gutes Toolkit (gtk oder Qt), weil Xlib/Xt ziemlich umstaendlich ist.
bye,
Chris
--
Christian Perle E-mail: christi...@tu-clausthal.de
Am Galgensberg 4 WWW: http://home.tu-clausthal.de/~incp/
38678 Clausthal/Germany ComputerGuitarKitesBicyclesBeerPizzaRaytracing
Juergen Steinel
> ELF binary
> Wie ist ein ELF binary ausgebaut?
> Wie wird es geladen?
> Wohin?
Hier koennte (hab' selbst noch nicht reingeseh'n) Dir die ELF-HowTo
weiterhelfen.
Bis dann...
Juergen
Sascha Bohnenkamp
>Linux.
>Mir fehlen vor allem Angaben zu folgenden Bereichen:
>
>Wie wird der ProtectMode unter Linux eingesetzt?
immer
>Wie bedeutet hier nicht das was in
>/usr/src/linux/arch/i386/kernel/head.S steht,
>sondern generelle Angaben, zu den verwendeten ProtectedMode Varianten
>und Features die genutzt werden. Auch wie die verschiedenen
>PM-Erweiterungen der Intel CPUs genutzt werden.
nur der '386 kompatible kram (auf jeden fall bis einschliesslich 2.0x)
ausser der bugs, die werden auch bei neueren gefixt :)
>User mode vs. Kernel mode
>Was ist das?
kernel-mode -> Betriebsystem (Linux)
user-mode -> anwendungen
normalerweise kann anwendung den kernel nicht aus dem trab bringen ... d.h.
keinen totalabsturz verursachen
alle hardwarenahen sachen und speicherverwaltung, prozessverwaltung findet
im
kernel statt ...
>Wie ist er realisiert?
wie 'wie'? der prozessor unterstuetzt das auf hardwareebene (super-mode)
>Wie kommt ein Programm in den einen oder anderen mode?
der kernel ist nach dem booten automagically in demselben ...
anwendungen selber koennen diesen mode nicht erreichen, allerdings
werden alle systemcalls (open,close,mmap etc.) vom kernel abgearbeitet und
wenn dabei was schief geht (falsche parameter etc.) wird das der anwendung
zulasten
gelegt und diese normalerweise abgeschossen (segfault,bus error,core-dump
etc.)
>Was bedeutet es für mein Programm wenn es in dem einem oder anderem
>läuft?
solange du keine treiber im kernel schreiben willst, laeuft dein programm
IMMER im
user-mode
>physikalisches memory layout
>Wie sieht der Speicher unter Linux aus?
kernel oder user mode?
user-mode: nahezu der gesamte phys. speicher + auslagerungsdatei(en) werden
der anwendung bis zu einer groesse
von 2GB (neuerdings glaub ich 3GB) zur verfuegung gestellt.
hardware-register etc. sind fuer anwendungen normalerweise nicht sichtbar
(koennen aber angefordert werden)
oberhalb von 3GB befindet sich (virtuell) der kernel fuer alle anwendungen
an der gleichen stelle.
kernel-mode: der kernel liegt oberhalb von 1MB, der bereich darunter wird
nicht verwendet, da dort hardwareregister etc. liegen der speicher der vom
kernel nicht benutzt wird wird den anwendungen zur verfuegung gestellt.
der kernel kann natuerlich nach 'belieben' auf daten im anwendungsbereich
(auch in der auslagerungsdatei) zugreifen.
>Welche Bereiche gibt es?
fuer anwendungen gibt es im prinzip nur einen bereich, und das ist der
speicher den sie 'sehen' koennen.
dieser speicher kann dann noch zum teil mit anderen anwendungen gemeinsam
benutzt werden (shared memory), oder/und eine im speicher abbilden (mmaped
files) etc. jeglicher anderer speicher ist fuer die anwendung nicht
erreichbar.
fuer den kernel gibt es halt speicher fuer ihn und speicher fuer die
anwendungen ...
>Wie werden sie eingesetzt?
s.o.
>Was passiert mit den EEPROM die knapp unter 1MB eingeblendet sind und
>die ganzen BIOS's (Mainboard, SCSI, VGA/VBE) enthalten?
werden im prinizip nicht genutzt ... man koennte auch sagen sie gehoeren dem
kernel ... :)
>Was passiert mit den Memory Mapped Speicherbereichen der PCI Cards?
die 'gehoeren' dem kernel und werden ggf. anwendungen (XServer etc.)
eingeblendet.
>logisches memory layout
0 -1MB unbrauchbar :)
1MB-?MB kernel
?MB-(phys speicher grenze) speicher fuer filebuffer und anwendugnen
+auslagerungsdateien fuer anwendungen
>wie sieht der speicher vor dem laden eines programms aus?
fuer die anwendung? leer :)
fuer den kernel? kann man nicht sagen ... da gerade andere programme laufen
werden
>wie danach? (ja, ich weiss das nicht alles geladen wird)
etwas voller ...
>wird das program segmentiert?
nicht zwangslaeufig ... normalerweise unterteilt man das programm in
bereiche fuer
das executable (read-only) und daten (read-writeable) ... das muss aber
nicht so sein
>wie sieht der speicher für das programm aus?
0-viel alles meins
>wo liegt der stack?
viel runter bis etwas weniger
>Wie wird es geladen?
haeppchenweise, was gerade gebraucht wird
>Wohin?
wo gerade platz ist
>Hardware unter Linux
>Kann ein Programm direkt auf die I/O-Ports zugreifen?
ja, sollte es aber nicht
>Kann ein Programm direkt auf Memory Mapped Register (SVGA) zugreifen?
ja, sollte es aber nicht
>Kann ein Programm direkt auf Memory Mapped Speicherbereiche zugreifen
>(Linear Frame Buffer) ?
ja, sollte es aber nicht
>Gibt es einen Mechanismus der unter Linux einen Zugriff mehrere
>Programme verhindert? (Semaphore's)
mutex,semaphore, und und und und ....
>
>Helfen würde mir auch ein Hinweis wo ich solche Informationen bekommen
>kann.
stevens - advanced programming in the unix-environment (addison wesley)
stevens - network programming in the unix-environment (addison wesley)
die lohnen sich wirklich !
>
>Es gibt einige Bücher, kann mir da jemand eines empfehlen?
s.o. und die laufen mit jedem *x !
>Ich suche quasi ein "PC intern" (Data Becker) für Linux, eine Mischung
>aus Einführung und Referenz mit Sourcecode-Beispielen.
ooh dafuer gibt es das kernel-driver programming von O'Reily glaub ich!
>Was das PC intern für Hardware und DOS-Programmierung ist, ist "der
>Petzold"
>für Win95-Programmierung. Gibt es sowas auch für X?
X-window system programming von barkakati / sams publishing
>Ach, eins noch. Ja ich habe alle dise READMEs und sonstigen kleinen
>Datei gelesen die da so über das ganze Dateisystem verteilt sind. Das
>was da unter /usr/src/linux/Documentation zu finden ist, ist es meiner
>Meinung nach nicht Wert Dokumentation genannt zu werden.
ist eher fuer den kernel gedacht
>Und bitte, den Hinweis, das der Sourcecode ja dabei ist, und man dort ja
>nachlesen könnte wie die Dinge funktionieren, empfinde ich als
>Frechheit. Ich habe nicht die Zeit und die Lust mich in fremden
>Sourcecode einzuarbeiten.
brauchst du ja nicht, anwendung benoetigen solche internals eigentlich nicht
Christian Kirsch
>
> Hi!
>
> Joerg Plate wrote:
>
> > Der Unterschied zwischen a.out und ELF interessiert micht nicht, das
> > macht der Compiler. ProtectedMode,BIOS,PCI-Kartenspeicher? Brauche
> > ich nichts drüber zu wissen. Wie ist der Speicher aufgebaut? Ist auch
> > egal, es gibt ja "malloc()". Wo liegt der Stack? Auch
> > uninteressant. SVGA-Register? Es gibt X :-)
>
> Sucherei wieder von vorne los.
>
dort
durchlesen oder sie erwerben, mit nach Hause nehmen und dann in Ruhe
studieren. Das zweite Vorgehen bietet sich an, wenn man öfter mal was
wissen will.
> > Das braucht man nur wenn irgendwelche Treiber schreiben will, aber
> > für normale Programme?
>
> Ach, tatsächlich?
> Ein normales Programm stellt doch etwas am Monitor dar oder?
> Also muß es ab und zu mal ein paar Pixel einfärben.
> Und ich weiss nicht wie du das machen willst ohne ein paar Dinge
> über dein System zu wissen.
>
Na ja, s.o. Unter Unix darf halt nicht jedes Programm beliebig auf jedes
Pixel zugreifen. Dafür gibt's so Dinge wie X.
Christian
Achim Linder
>
> Hallo!
>
> Ich brauche Hilfe. Ich suche Informationen zum Programmieren unter
> Linux.
>
Seit September gibt´s "Linux-Gerätetreiber" von Alessandro Rubini in
einer deutschen Übersetzung (O´Reilly). Ist IMHO sehr gut lesbar und
behandelt ansatzweise auch Kernel-Interna. (Das Original ist vermutlich
noch besser :). Die Literatur zum Thema Linux-Kernel ist
zugegebenermaßen noch etwas dünn gesät, dafür aber ohne NDA erhältlich.
Achim
Michael Brandtner
Uli Laube <uli....@wiesbaden.netsurf.de> writes:
Hallo,
> Dann sag mir wo die Doku zu X zu finden ist. Dann geht die gleiche
> Sucherei wieder von vorne los.
Titel : X Window System
Autoren: Robert W. Scheifler, James Gettys
Verlag : Digital Press
ISBN : 1-55558-154-4
Das sollte dich erst mal beschaeftigen.
Ich verstehe aber nicht, warum Du nicht eines der gaengigen Toolkits
verwenden willst.
>> Das braucht man nur wenn irgendwelche Treiber schreiben will, aber
>> für normale Programme?
>
> Ach, tatsächlich?
Ja, er hat absolut recht.
> Ein normales Programm stellt doch etwas am Monitor dar oder?
> Also muß es ab und zu mal ein paar Pixel einfärben.
> Und ich weiss nicht wie du das machen willst ohne ein paar Dinge
> über dein System zu wissen.
Willst Du direkt auf die Hardware zugreifen ?
Wozu ?
Der Kernel hilft dir da auch nicht weiter.
Benutze X, bzw. ein entsprechendes Toolkit deiner Wahl.
> Bei Bibliotheken von anderen Leuten ist wieder das Problem die
> Doku zu bekommen.
Die Toolkits sind meist recht gut dokumentiert.
>> Was willst Du eigentlich machen?
>
> Ich will es einfach nur wissen. Ist das so schwer zu verstehen?
Deine Fragen sind etwas ´strange´.
Es klingt verdaechtig nach einem DOS-Hacker der unter Linux auf der
Suche nach seiner alten Arbeitsumgebung ist.
Deshalb die Fragen.
Gruss
Michael
--
-------------------------------------------------------------------
Michael Brandtner m...@evolution.org
-------------------------------------------------------------------
Joerg Uecker
> Es klingt verdaechtig nach einem DOS-Hacker der unter Linux auf der
> Suche nach seiner alten Arbeitsumgebung ist.
Frei nach einem Dijkstra-Zitat:
DOS - It is practically impossible to teach unix programming to
students that have had a prior exposure to DOS: as potential unix
programmers they are mentally mutilated beyond hope of regeneration.
--
J"org Uecker <j...@pirx.ruhr.de>
Bernd Knochenhauer
>
>DOS - It is practically impossible to teach unix programming to
>students that have had a prior exposure to DOS: as potential unix
>programmers they are mentally mutilated beyond hope of regeneration.
_Das_ hat Dijkstra gesagt ? Cool <g> das hänge ich mir über´s Bett.
--
Software, Systemberatung, Entwicklung - UNIX & NT, UML, C++, RDBMS
e-mail: bo...@castle.aball.de - phone: 49 511 7244795
Bernd Knochenhauer
On 30 Sep 1998 19:11:29 GMT, Christoph Kliemt <CKl...@t-online.de> wrote:
>
>> Es wird zum Beispiel nicht erklärt warum etwas so gelöst wurde wie
>> es gelöst wurde, das es mit einer anderen Lösung diese und jene
>> Probleme gab und das es deswegen so ist wie es ist. Oder generell
>> das es diese und jene Möglichkeit gibt das Problem zu lösen.
>
>Sag mal: Was willst Du eigentlich ? Beschützende Werkstätte für
>eNTengenervte oder was ? Wenn Dir die Doku nicht passt, dann schreib
>sie selbst ! Soweit ich weiss gibt "Linux Inc" nur einen geringen Teil
>des Etats für Promo,Doku und so aus...
Was soll das ? Statt dem Menschen ein paar Pointer auf brauchbare Infos
zu geben, kriegt er von Dir nur ein paar äußerst dämliche Kommentare
um die Ohren gehauen, die Du Dir auch dahin hättest stecken können, wo
nie die Sonne scheint. Das ist so ähnlich, als wenn ein Kunde in einen
Laden kommt und nach einem Produkt fragt, und der Verkäufer ihn dann
mit "was willst Du, Du Vogel ? Wenn Dir hier die Luft zu dünn ist, dann
verpiss Dich. Da hinten ist der Ausgang" rausschmeisst. Bist Du eigentlich
noch ganz dicht ?
>> Außerdem sind .c files nicht einheitlich. Jeder mitwirkende Programmierer
>> hat seinen Teil anders "gestaltet", was die Verständlichkeit nicht gerade
>> verbessert.
>shit happens...
Uhhh - klasse Bemerkung. Eine glatte 10 auf der nach oben offenen Richter-
skala dummer Äusserungen in Newsgroups. Mach weiter so, und Du läufst Adam
noch den Rang ab.
>Tip : Beschwer Dich beim Hersteller !
Tip: wunder Dich nicht, wenn sich Linux-Newbies nach solchem unglaublich
nützlichem Geblubber wie von Dir mit Grausen wieder abwenden.
Prost,
Bernd
Holger Petersen
>>DOS - It is practically impossible to teach unix programming to
>>students that have had a prior exposure to DOS: as potential unix
>>programmers they are mentally mutilated beyond hope of regeneration.
>_Das_ hat Dijkstra gesagt?
Glaube ich nicht :-)
Stammt nicht von ihm die Aussage:
"malloc() considered harmful"
und:
"Don't use 'C' for Internet-Programming or you will get one buffer-
overflow after the other"
SCNR, Holger
PS: Ich habe hier eine Ethernet-Spezifikation, die in (Concurrent-)
Pascal abgefasst ist...
Felix Schroeter
In article <6uvgb0$8a6$1...@sparcserver.lrz-muenchen.de>,
<ku...@lpr.e-technik.tu-muenchen.de.nospam> wrote:
>[...]
>Der Kernel greift AFAIR immer auf den physikalische Bereich zu
>(also ohne MMU, d.h. so wie unter DOS)
Nein. Der Kernel hat genau das selbe Page-Mapping, wie der Prozess,
der auf dieser CPU als letztes lief. Nur, dass er, da er privilegiert
ist, auch den Kernel-Teil des Mappings zugreifen kann.
>[...]
>: wird das program segmentiert?
>Code, Daten und Stack
Aber nicht mit der Segmentierung des ix86. Dafuer gibt es genau 2
Segmentdeskriptoren, die beide den kompletten virtuellen Speicher
ueberdecken, einer als Codesegment (lesbar+ausfuehrbar), einer
als Datensegment (lesbar und schreibbar). Der eigentliche Speicherschutz
laeuft mit der Paging-Einheit des ix86.
>[...]
Gruss, Felix.
Joerg Uecker
> _Das_ hat Dijkstra gesagt ? Cool <g> das hänge ich mir über´s Bett.
Nein (deshalb auch frei nach), das Orginalzitat heisst:
BASIC - It is practically impossible to teach good programming to
students that have had a prior exposure to BASIC: as potential
programmers they are mentally mutilated beyond hope of regeneration.
-- Dijkstra, "How do we tell truths that might hurt",
ACM Sig Plan Notices, May 82
Gleiche Quelle:
APL is a mistake carried through perfection. It is the langage of the
future for the programming techniques of the past: it creates a new
generation of coding bums.
The use of COBOL cripples the mind; its teaching should therefore be
regarded as a criminal offense.
PL/I - the fatal disease - belongs more to the problem set than to
the solution set.
FORTRAN, the infantile disorder, by now nearly 20 years old, is
hopelessly inadequate for whatever computer application you have in
mind today: it is now too clumsy, too risky, and to expensive to use.
In the good old days, physicists repeated each other's experiments,
just to be sure. Today they stick to FORTRAN, so that they can share
each other's programs, bugs included.
Joerg Plate
Ich kenne z.B.
"Wenn Studenten einem Basic-Rechner ausgesetzt waren sind sie als
potentielle Programmierer unheilbar geistig krank."
"APL ist ein Fehler der bis zur Perfektion ausgeführt wurde."
"Cobol verwirrt das Gehirn. Diese Sprache zu lehren sollte als
kriminelle Tat verfolgt werden."