kernelprogrammierung / einstieg

[cuedee]

hi leute,

ich wusste nicht genau, wo ich hin soll mit meinem beitrag; ich hoffe, ich kann 'hier' stehenbleiben.

nun denn: ich habe mittlerweile etwa 5 jahre programmiererfahrung, mehr oder weniger professionell. wahrscheinlich eher weniger

angefangen hat alles mit einem msvc++ 6.0 vor fast sechs jahren. davor natürlich sowas wie qbasic und so nen schrott, aber das zählt ja nicht.

was ich im studium an programmiertechniken gelernt habe, ist nicht mehr als ein schlechter witz (fh-niveau eben). deswegen habe ich stetig versucht, mich selbst weiterzubilden und bin irgendwann im zuge meiner ersten linux-distri auf die programmierung unter linux gestossen.

da sich nun mein studium dem ende nähert (noch etwas mehr als 1 jahr), würde ich meinen horizont gerne erweitern und habe deswegen folgende frage an euch:

hat sich schon mal jemand ernsthaft mit kernelprogrammierung auseinandergesetzt? und wenn ja... sollte ich dazu ein gutes buch lesen (was ist ein gutes buch?) oder reichen die dokumente im internet?

-- ich weiss... ich könnte ja selbst suchen... aber genau das ist mein problem. ich weiss absolut nichts über die kernelarchitektur und wollte einfach wissen, WIE und WO ich damit anfangen soll.

wenn einer von euch ein paar tipps hätte, wäre ich euch sehr dankbar!

[Bert]

Ich hab zwar selber keine Erfahrungen mit Kernelprogrammierung (ich mag reines C nicht so) aber in den letzten Linux-Magazinen war da eine recht gute Einführung zu. Allerdings auf Treiberprogrammieung zugeschnitten. Vielleicht kanst Du Dir diese ja besorgen.

Ich hab das ganze mal verschoben.

[abi]

evtl willst du dich ja mal auf http://www.kernelnewbies.org umsehen.
ABER: wenn du nicht wirklich Erfahrung damit hast, oder du selber von dir denkst das entsprechende C Kenntnisse noch nicht so ausgereift sind, dann programmier lieber an anderen OpenSource Projekten mit. Der Kernel ist eine Sache, da sollten meiner Meinung nach nur Personen ran, die auch _wirklich_ Fundierte Kennntnisse darüber haben, was sie tun, da schon der kleinste Fehler große Auswirkungen haben kann.

Es gibt genügend andere wirklich große OpenSource Projekte die auch dringend Hilfe benötigen, ich verstehe nicht, wieso immer gleich alle meinen, es würde was bringen, sich gleich mit Kernelprogrammierung zu beschäftigen.

[spiffi]

Und wie erwirbt man fundierte Kenntnisse in der Kernelprogrammierung, wenn nicht durch Kernelprogrammierung?
Es ist ja nun auch nicht so, als wenn jeder Newbie-Patch gleich im offiziellen Kernel landen würde.

[abi]

Und wie erwirbt man fundierte Kenntnisse in der Kernelprogrammierung, wenn nicht durch Kernelprogrammierung?
Es ist ja nun auch nicht so, als wenn jeder Newbie-Patch gleich im offiziellen Kernel landen würde.

Es geht meiner Meinung nicht ausschliesslich um die Kenntnisse der Kernelprogrammierung. Wenn man sich ansieht, welche Personen an Kernel mitarbeiten, wird man schnell feststellen, das diese Personen sich hauptsächlich mit Hardwarenaher Programmierung beschäftigen und das nicht nur im Privaten umfeld, sondern auch Hauptberuflich (und das meist über Jahre hinweg)

Man muss ja nicht gleich von 0 auf 100 gehen, wenn man der Community was nützliches tun will. Erstmal "reinschnuppern" wie das ganze überhaupt abläuft. Ein Patch für *OpenOffice, der auch angenommen wird, bringt der Community mehr, als ein Kernel Patch, der aufgrund von schlechtem Codingstil oder sontigen Fehlern abgelehnt wird.

Natürlich kann er von mir aus damit anfangen, sich mit Kernelprogrammierung zu beschäftigen (von kleinen Privaten Patches bis hin zu Dingen die irgendwann in den Offiziellen Kerneltree einfliessen), da hab ich nichts dagegen, jeh mehr Personen das tun, desto besser ist es für uns alle, aber er sollte sich auch darüber im klaren sein, was für eine Verantwortung er dann trägt.

[*] reines Beispiel.

[BeS]

Hallo,
ein sehr gutes Buch ist sicher "Linux - Gerätetreiber" von O'Reilly, das Buch gibt es auch online: http://www.oreilly.de/german/freebooks/ ... book1.html

[debian_noob]

Hallo cuedee,

Schau dich mal bei O'reilly um. Da gibt es ein Buch Namens "Understanding the Linux Kernel", das würde ich dir empfehlen. Allerdings mach dich darauf "gefasst", dass es
1) nur den "alten" Kernel (2.4) durchnimmt, du wirst also später dich noch mit den neuen Features des 2.6 auseinandersetzen müssen,
2) es verlangt dass du C wie eine Muttersprache sprichst.

Genau da liegt auch der Haken. Nimm dir unbedingt ein gutes Buch für C dazu, wenn du nicht unbedingt mit C aufgewachsen bist. Das wird dir helfen, glaub mir; ich habe das obige Buch auch schon zu zwei dritteln fertig.

So jetzt zu try:
Es hilft sehr, wenn man den Kernel kennt.
1) Mit den Beispielen an Codierungsarbeit kann man sich einen guten Codierungsstil aneignen.
2) Mit der Arbeitsweise des Kernels als Know-how, kann man einige Punkte besser verstehen was "Linux" (<- hier als eine Distri zu verstehen) betrifft.
Überhaupt: Viele sagen, dass sie sich mit Linux auskennen. Aber sie meinen meistens ein Portfolio an Applikationen, nicht Linux (also den Kernel) selbst. Wenn man sich mit dem Kernel auseinandersetzt, dann kann man wirklich sagen, dass man sich mit Linux auskennt.
3) Nur weil man sich mit dem Kernel (oder auch zum Beispiel mit dem Debian Paketmanagement) beschäftigt, heisst das nicht, das man Patches dafür schreibt. Man will einfach nur das ganze mal verstehen(und vielleicht mal etwas herumexperimentieren: wer weiss, vielleicht entwickelt cuedee ja Serverrollen und Schattenkopien in den Kernel
. ) .

euer debian_noob

[cuedee]

hi leute,

vielen, vielen dank!!! das ist ja weit mehr resonanz als ich erwartet hatte!

zunächst bin ich dankbar für die vielen verschiedenen meinungen.

ich kann dazu soviel sagen:

ich masse mir nicht an zu behaupten, ich könne offizelle patches für den kernel schreiben. alles was ich will, ist zu *verstehen* wie linux (sprich: der kernel) funktioniert.

einige meiner vorredner sehen das ähnlich. natürlich akzeptiere ich auch try's meinung: wahrscheinlich ist kernel-programmierung wirklich ein wenig hochgegriffen für einen wie mich-- einen fh-studenten, der gerne programmiert.

aber ich bin einfach immer wissbegierig, und das macht doch auch unsere gemeinde aus, denke ich. ob das nun der kernel ist oder openoffice - um mal die beispiele aufzugreifen - ist letzten endes wahrscheinlich egal.

ich danke euch für eure kommentare!

[BeS]

Hallo,

2) Mit der Arbeitsweise des Kernels als Know-how, kann man einige Punkte besser verstehen was "Linux" (<- hier als eine Distri zu verstehen) betrifft.

Du meinst hier doch sicher den Kernel, oder warum soll ich eine Distribution besser verstehen wenn ich ein Buch über Linux gelesen habe?

Überhaupt: Viele sagen, dass sie sich mit Linux auskennen. Aber sie meinen meistens ein Portfolio an Applikationen, nicht Linux (also den Kernel) selbst. Wenn man sich mit dem Kernel auseinandersetzt, dann kann man wirklich sagen, dass man sich mit Linux auskennt.

Deswegen gibt es auch zwei Begriffe dafür
Ich halte es immer so, das wenn ich von Linux spreche auch das meine was Linus Torvalds so genannt hat -> seinen Kernel.
Wenn ich vom Betriebssystem als ganzes spreche sage ich GNU/Linux, so gibt es bei mir eigentlich nie eine Verwechslung.

[Olaf Dietsche]

Je nachdem, in welchem Bereich du was lernen möchtest, findest du hier etwas:

Memory management:
http://www.nongnu.org/lkdp/files.html
http://www.linux-mm.org/

Weitere Links:
http://www.linux-mm.org/kernel-links.shtml

Unter
http://www.tldp.org/guides.html
findet sich z.B.

Linux kernel internals
http://www.moses.uklinux.net/patches/lki-single.html
und
The Linux Kernel Module Programming Guide
http://www.tldp.org/LDP/lkmpg/index.html

[bollin]

Ich habe meine Antwort unter http://www.debianforum.de/forum/viewtopic.php?p=87972 'verpostet'.

Torsten

[Torsten]

Moinsen,

um mal wieder das Thema aufzugreifen.

was ich im studium an programmiertechniken gelernt habe, ist nicht mehr als ein schlechter witz (fh-niveau eben). deswegen habe ich stetig versucht, mich selbst weiterzubilden und bin irgendwann im zuge meiner ersten linux-distri auf die programmierung unter linux gestossen.

Bitte nicht so das Niveau einer Ausbildung an einer FH in den Dreck ziehen.

Ich selbst studiere, wenn auch in den letzten Zügen, an einer FH im Studiengang Informatik.
Und es kommt immer drauf an, was man selbst daraus macht. Wenn auch nur begrenzt, so glaube ich dennoch an die Fähigkeiten vieler Dozenten. Auch wenn jene an einer FH tätig sind. An meiner FH ist beispielsweise ein überaus fähiger Mann, der sich in Sachen Betriebsystemen (jeglicher Art) und deren Programmierung besten auskennt (der hat am "Tanenbaum" mitgearbeitet).
Bei dem hatte ich nur wenig Vorlesung. Dennoch, ich habe mir einfach eine Aufgabe bei ihm geschnappt und mich darin regelrecht ergossen.
Nebenbei, sprich abends und am Wochenende, habe ich einen Treiber unter Linux um die Fähigkeit von Message Queues in den userspace (und das ist richtig pervers) erweitert. Daraufhin habe ich unter VxWorks intensiv Thread- und MessageQueue Programmierung betrieben. Und das alles unter C. Und das geht wirklich ins Element. Da geht es dann auch nicht mehr darum, wie gut man C kann, sondern auch darum, wie gut msn mit der jeweiligen Architektur umgehen kann. Kleines Beispiel: big endian und little endian.
Sowas wird auch nicht in einer Vorlesung an die Tafel geschrieben. Sowas muss man sich beibringen. Das bleibt nicht aus. Oder es baut auf vorhergehenden Vorlesungen auf.

Mein Tipp:
Kauf Dir eine vernünftige digitale (kein Muss) I/O-Karte bei Reichelt (oder auch günstig bei ebay zu bekommen) und aktiviere das Teil.
Einerseits hast Du dort beste Treiberprogrammierung, wie auch Programmierung im userspace (man muss den Treiber ja auch mal testen).

Sanfte Grüße

Torsten

[pdreker]

Ich habe zwar keine Ahnung, was einem an einer FH so in Sachen Programmierung beigebracht wird, aber aus meiner persönlichen Erfahrung sollte das "relevanter" sein, als das was einem an der Uni beigebracht wird (Uni: eher Theorie, FH ist praktischer).

Was Programmierung im allgemeinen angeht, braucht man 3 Dinge: Erfahrung, Erfahrung, Erfahrung. Diese bekommt man natürlich nur durch... (Trommelwirbel) Programmierung. Es schadet natürlich nicht sich auch die theoretische Seite anzueignen, aber das kann man auch "on Demand" machen, also während man programmiert.

Kernelprogrammierung: Am besten bei Treibern anfangen. Die sind auch mit wenig Erfahrung zu verstehen, wenn man ein wenig C versteht. Oft bleiben einem zwar die Details verborgen, das sind dann aber normalerweise die Hardwarespezifischen Dinge. Die eigentliche Struktur der Treiber ist erstaunlich einfach: Ein Handvoll Funktionen (init, deinit, input, output, usw.) die implementiert werden, und deren Pointer dann in ein struct eingetragen werden müssen. Das war es oft schon... Am besten lernt man sowas, indem man sich einfach einen vorhandenen Treiber als Vorlage nimmt... Bei den USB Treibern ist sogar ein "Demo Treiber" im Kernel dabei, der demonstriert, wie man's macht [1]... Meistens findet man dann recht schnell heraus, das auch im Kernel "nur mit Wasser gekocht" wird: Wenn man die API einmal kapiert hat, ist der Rest "nur noch" Handwerksarbeit.

Ausserhalb von Treibern (Block Subsystem, Network Stack, VMM, Scheduler usw.) wird's dann schwieriger, aber wenn man sich von unten hocharbeitet wird auch das irgendwann verständlich...

[1] file:/usr/src/linux/drivers/usb/usb-skeleton.c

Patrick