Programmieren unter Linux
Jan C. Faerber
Und auch nicht die Zeit jetzt gemütlich Tutorials durchzuackern mit
weiterführenden Beispielen.
Mich würds nur prinzipiell interessieren - vielleicht kommt zumindest
mal ein kleines Applet heraus dabei:
Wie geht man unter Linux generell vor, wenn man ein Programm schreibt,
dass im Idealfall schlußendlich Hardware steuert - also etwa ein
Treiber sein kann - weil es soetwas für Linux z.B. nicht gibt?
Kann man da Unix und Linux vermantschen - also einsmachen? (Wobei ich
Unix überhaupt nicht kenne - außer Linux.)
Gibts da eine Checkliste?:
C/C++ muß es unbedingt sein oder Perl oder Java???
Dann die USB Protokoll / Spezifikationen studieren.
Die Hardware genau mit Bauplänen unter die Lupe nehmen oder mit so
einer Art Portscann bombardieren? Ich weiß, der Vergleich ist
unangebracht - aber irgendwie muß man wohl herausfinden, welche
"Hebel" in einer Hardware stecken, die man dran-pluggen will.
Ich frag nur, weil ich mir denk, dass ich mit einer Zielvorstellung,
eine konkrete Sache zu tippseln, besser auch ein Argument finden kann,
mir entsprechende Informationen zu Gemüte zu führen.
Das soll jetzt kein duftendes Stück Käse in einer Mausefalle sein -
Ist eher so eine Frage von mir "Was ich schon immer wissen wollte."
Jan Kandziora
>
> Wie geht man unter Linux generell vor, wenn man ein Programm schreibt,
> Treiber sein kann - weil es soetwas fï¿œr Linux z.B. nicht gibt?
>
Dafï¿œr gibt es keine allgemeingï¿œltige Antwort, weil es zu viele verschiedene
Gerï¿œteklassen gibt.
Alles was auf dem Mainboard drauf ist braucht ï¿œblicherweise einen
Kerneltreiber (es gibt inzwischen aber auch einen Kernel-Helper dafï¿œr) und
wird in C programmiert -- kein C++, nur C und evtl. Assembler.
Fï¿œr alles andere kannst du Treiber auch im Userspace machen, da bist du in
der Wahl der Programmiersprache vï¿œllig frei. ï¿œblicherweise gibt es aber
schon bestimmte Frameworks fï¿œr die Gerï¿œteklasse z.B. libusb fï¿œr USB-Gerï¿œte
oder SANE fï¿œr Scanner. Man sollte das Rad also nicht neu erfinden, sondern
diese existierende Software erweitern. Dann nimmt man logischerweise eine
Programmiersprache, bei der man das existierende Framework leicht benutzen
kann.
> Kann man da Unix und Linux vermantschen - also einsmachen? (Wobei ich
> Unix ï¿œberhaupt nicht kenne - auï¿œer Linux.)
>
Das ist nicht OS-abhï¿œngig, sondern von den existierenden Treiberframeworks.
> Dann die USB Protokoll / Spezifikationen studieren.
>
Unnï¿œtz. Es sei denn, du hast genau die Protokollstruktur von dem Gerï¿œt
vorliegen. Wenn es eine Standard-USB-Gerï¿œteklasse ist, gibt es dafï¿œr schon
einen Treiber. Im anderen Fall muss du die Kommunikation des
MS-Windows-Treibers mithorchen und daraus das Protokoll zurï¿œckentwickeln.
Ist was fï¿œr Leute mit harten Nerven.
> Die Hardware genau mit Bauplï¿œnen unter die Lupe nehmen
>
Bringt auch nichts, denn man bekommt keine Bauplï¿œne und in den fast allen
Gerï¿œten stecken heutzutage nur Customchips, zu denen man ebenfalls keine
Infos bekommt.
>
> Ich frag nur, weil ich mir denk, dass ich mit einer Zielvorstellung,
> eine konkrete Sache zu tippseln, besser auch ein Argument finden kann,
> mir entsprechende Informationen zu Gemï¿œte zu fï¿œhren.
>
Wenn du nicht programmieren kannst ist die Erstellung von Gerï¿œtetreibern das
letzte, zu dem du dich berufen fï¿œhlen solltest. Obwohl, fï¿œr MS-Windows
macht das ja auch fasst immer der Praktikant. Anders sind die ï¿œblichen
hirnlosen Protokolle, ï¿œbelsten Bugs und sonstigen Designschwï¿œchen
kommerzieller Treibersoftware kaum zu erklï¿œren.
Mit freundlichem Gruￜ
Jan
Jan C. Faerber
> Wenn du nicht programmieren kannst ist die Erstellung von Gerätetreibern das
> letzte, zu dem du dich berufen fühlen solltest. Obwohl, für MS-Windows
> macht das ja auch fasst immer der Praktikant. Anders sind die üblichen
> hirnlosen Protokolle, übelsten Bugs und sonstigen Designschwächen
> kommerzieller Treibersoftware kaum zu erklären.
>
> Mit freundlichem Gruß
>
> Jan
Der Praktikant - lol.
Vielen Dank für die ausführliche Antwort.
Das mit dem 'Mithorchen' klingt sehr interessant. So eine Art Zeitlupe
oder USB-Ethereal wohl.
Das einzige, was ich nicht verstanden hab, wobei ich da jetzt nicht
viel an Infos herauszuholen trachte: Die Sache mit OS-Unabhängigkeit:
Die Frameworks sind OS-unabhängig?? Oder nur im Rahmen Linux und Unix?
Bernd Petrovitsch
[...]
> Das einzige, was ich nicht verstanden hab, wobei ich da jetzt nicht
> viel an Infos herauszuholen trachte: Die Sache mit OS-Unabhängigkeit:
> Die Frameworks sind OS-unabhängig?? Oder nur im Rahmen Linux und Unix?
Bernd
--
"Designed for Windows" ist das Äquivalent zu Entwicklungsprinzipien
der russischen Armee: es muß so gut sein, daß es ein Bauerntrampel
nur schwer mutwillig kaputt kriegt. - Arnim Sommer
Jan Kandziora
>
>> Wenn du nicht programmieren kannst ist die Erstellung von Gerï¿œtetreibern
>> das letzte, zu dem du dich berufen fï¿œhlen solltest. Obwohl, fï¿œr
>> MS-Windows macht das ja auch fasst immer der Praktikant. Anders sind die
>> Designschwï¿œchen kommerzieller Treibersoftware kaum zu erklï¿œren.
>>
>
>
Das ist leider nicht erfunden... Beispiel: Mustek PowerMust 800 USV
Wird beworben mit "Linux-Treiber beigelegt". Eine CD, ok, runterladen kann
man den identischen Treiber auch irgendwo. Also ausprobiert.
Hmm. Der Treiber braucht root-Zugriff. Naja, vermutlich um den Rechner
automatisch runterzufahren. Ok.
ï¿œhm, aber wieso will der denn X11-Libraries? Ich hab das Ding doch fï¿œr den
Server gekauft. FAIL1
Nagut, X11 nachinstalliert. Was zum Teufel will der da eigentlich anzeigen?
Mal starten. Hmm. Geht nicht mit sudo als normaler Benutzer, nur mit "ssh -X
root@localhost". Der will also tatsï¿œchlich als root X11 benutzen? FAIL2
Oh, ein buntes Fenster mit "Strom", der vom Netz zur "Batterie" lï¿œuft. Toll,
wie unnï¿œtz. ï¿œhm, wer braucht denn da 100% Prozessor? Mal kurz das
Scheiï¿œding beenden. Oh ja, der Verdï¿œchtige wars. FAIL3
Zum Glï¿œck gab es einen Treiber fï¿œr das Gerï¿œt in "nut", dem gï¿œngigen
Unix-Treiberframework fï¿œr USVs.
> Das mit dem 'Mithorchen' klingt sehr interessant. So eine Art Zeitlupe
> oder USB-Ethereal wohl.
>
Keine Zeitlupe, nur einfach alles in eine Protokolldatei mitschreiben und
danach auswerten.
> Das einzige, was ich nicht verstanden hab, wobei ich da jetzt nicht
> viel an Infos herauszuholen trachte: Die Sache mit OS-Unabhï¿œngigkeit:
> Die Frameworks sind OS-unabhï¿œngig?? Oder nur im Rahmen Linux und Unix?
>
Innerhalb der Unix-Familie sind es fast ï¿œberall dieselben Treiberframeworks.
Also auch bei BSD, Solaris, MacOS-X etc. Ab und zu dreht Apple mal
Extrawï¿œrste, meist nicht.
MS-Windows ist natï¿œrlich vï¿œllig anders, aber auch da gibt es von manchen
Frameworks Portierungen, meist auf Basis von Cygwin oder Mingw.
Jan Kandziora
>
> Was meinst Du konkret mit dem Buzzword "Frameworks"?
>
Scannertreiber. Nut fï¿œr USV-Treiber. /dev/input fï¿œr Keyboard, Maus,
Joystick, Grafiktablett. Usw usw. Kann man alles auch anders und selbst
machen, wer es sich einfach machen will nutzt die vorhandenen
Rahmenprogramme und bastelt da was fï¿œr.
count zero
> Hab leider keine weitgreifenden Programmierkenntnisse.
> Und auch nicht die Zeit jetzt gemütlich Tutorials durchzuackern mit
> weiterführenden Beispielen.
> Mich würds nur prinzipiell interessieren - vielleicht kommt zumindest
> mal ein kleines Applet heraus dabei:
Vielleicht doch oder nicht?
> Wie geht man unter Linux generell vor, wenn man ein Programm schreibt,
> dass im Idealfall schlußendlich Hardware steuert - also etwa ein
> Treiber sein kann - weil es soetwas für Linux z.B. nicht gibt?
> Kann man da Unix und Linux vermantschen - also einsmachen? (Wobei ich
> Unix überhaupt nicht kenne - außer Linux.)
Falls du dich doch zum lernen entscheidest mit
http://www.digitemp.com/
könntest du zu einem Erfolgserlebnis kommen.
Die Software ist bei den meisten Ditributionen als digitemp in
ihren Paketen vorhanden.
als Buch für weitere Ideen
*Linux Hardware Hackz*
von Jürgen Plate
--
ln -s /dev/cerebro /dev/null is full
Was ich denke ist leer und es quillt über.
Pseudonym...count.zero@interrupt; verarbeiten, lernen endet bei Null.
Jan C. Faerber
> Keine Zeitlupe, nur einfach alles in eine Protokolldatei mitschreiben und
> danach auswerten.
Das mit der Zeitlupe hab ich einmal in einem Buch "hackertales"
gelesen. Das war aber mehr prosa - als getippsel.
In Linux gibts sicher immer (oder auch nicht? *ggg*) irgendwelche
Protokolldateien. Aber anscheinend gibts auf Windows auch
Möglichkeiten, so eine Art isolierten Versuchszustand zu erzeugen, um
nachvollziehen zu können, wie sich ein Virus ungefähr fortarbeitet.
Dazu kann man die einzelnen Prozesse ganz langsam ablaufen lassen.
Warum dies nicht über Logs und Protokoll-Dateien geht, weiß ich auch
nicht. Das ist aber eher eben eine Windows-Gschicht, worums
anscheinend nun dann eben geht, wenn man einen Windows-Treiber
ummodeln will und ihn sozusagen kennen lernen möchte.
Obs das nun wirklich gibt oder nicht, kann ich garnicht beantworten.
Wird wohl von irgendwoher einen Ursprung haben.
Und ob ich nun nicht darum herum komme, Tuts zu studieren und Zeit
aufzuwenden, sei auch für mich zumindest mal dahingestellt. Ich freu
mich jedenfalls wahnsinnig, dass soviel Feedback kam.
Es war zumindest einmal ein Kontraposting meinerseits zu meinen
fallweisen Fragen, die irritierend nach irgendwelchen simplen Befehls-
Syntaxen abzielen. Wollt mir nur mal ein Bild machen. Also dass es
z.B. C sein muß, wenn man richtig "drinnen stecken" kann. Das hab ich
mir zumindest herausgelesen.
Ist sicher richtig in gewisser Weise, dass man, wenn man eine
Programmiersprache kann, somit auch alle anderen kann. Jedoch stimmt
dies auch wieder erst dann, wenn man einige Zeit damit verbracht hat,
eben eine konkrete Programmiersprache zu lernen - insbesondere die
Eigenheit der Generation / Eigenschaft der P.Sprache - abgesehen jetzt
mal von der Syntax.
Jan C. Faerber
> Die Zeit dafür wirst du dir zur Verfügung stellen müssen!
> Vielleicht doch oder nicht?
> Falls du dich doch zum lernen entscheidest mithttp://www.digitemp.com/
> könntest du zu einem Erfolgserlebnis kommen.
> Die Software ist bei den meisten Ditributionen als digitemp in
> ihren Paketen vorhanden.
> als Buch für weitere Ideen
> *Linux Hardware Hackz*
> von Jürgen Plate
Jo - und es geht halt immer noch darum, was einmal war. Was früher
war.
Und wenn ich da lieb vor mich hin schreib. Dafür krieg ich keinen
Schmarrn. Das ist mir schon klar. da spucken die Leut vielleicht bloß
in meinen Hut - oder auch hoffentlich nicht. Aber wenn sie
hineinspucken, dann wohl eher deswegen, weil sie sehen, dass es nur zu
Scheiße führt. Wenn sie nicht hineinspucken ... ja dann deswegen, weil
sie sehen, dass da was war. Darum gehts halt.
Und das Schreiben ist ja kein Gespräch. Wenn ich spreche, dann gehts
ja wohl auch weniger darum, ob ich recht hab oder nicht. Es geht mehr
darum, ob ich endlich gewillt bin, langsam zu denken.
Die schnellen Gedankengedänge sind ja einen Scheiß wert.
Ob ich nun weiß, was x += 1 bedeutet oder nicht... Wen juckts?
Nur wenns irgendwo in einem Programm-File drinnen steckt das funzt.
Oder wenns nicht funzt, dann dass ich wen anlabern kann und um Hilfe
winseln kann.
Schon klar - keine Müdigkeit vorschützen! Attacke! Kein Selbstmitleid.
Linux und OpenSource ist halt gratis. Aber die Zeit ist eben auch ein
wesentlicher Faktor.
Ob ich mir nun 330.- Euro leisten muß oder einen Arsch voll Lektionen,
die eine Auszeit in der Einsiedelei erfordern, kommt sich aufs Gleiche
im Endeffekt heraus.
Somit sind billigere Dinge manchmal besser. :-/