Treiber... - würde mich mal interessieren

Seemann

Greenhorn
Hallo FreeBSD-Freunde!

Viele Gerätehersteller kooperieren mit den großen Kommerziellen (MS und Apple) in der Computerbranche und geben die Informationen ihrer Geräte nicht frei. Einen passenden Unix-Treiber für solche Geräte zu finden gestaltet sich dann als recht schwierig, wenn nicht gar quasi unmöglich.
Nun, wie wohl allgemein bekannt ist, basiert Apples OS-X auf FreeBSD. Daher dürfte es doch eigentlich keinen größeren Aufwand darstellen, mit OS-X-Treiber die Hardware auch unter FreeBSD korrekt betreiben zu können; und im besonderen müßten doch Drucker, für die keine Unix-Treiber verfügbar sind, damit bestens betrieben werden können (evtl. sogar unter Linux!), da ja cups unter der Schirmherrschaft von Apple steht. :confused:

Was meint Ihr dazu, oder weiß da jemand sogar genaues zu berichten, was dafür oder dagegen spricht, bzw. hat schon Erfahrungen damit gemacht, einen Treiber zu modifizieren und an FreeBSD anzupassen?

Vielleicht gehört aber auch die Kenntnis darüber zum allgemeinen Hintergrundwissen von FreeBSD, und Ihr seid über diese Frage nun verwundert. In diesem Fall muß ich mich damit entschuldigen, daß FreeBSD noch absolutes Neuland für mich ist, und ich erst ganz am Anfang stehe, mich in dieses Betriebssystem einzuarbeiten; und hierbei blitzte dieser Gedanke in mir auf. :gpaul:
:o

Gruß
Seemann
 
Nun, wie wohl allgemein bekannt ist, basiert Apples OS-X auf FreeBSD.

Und genau da liegt der Fehler. OS X hat einen eigenen Kernel (Mach Microkernel) der nix mit FreeBSD zu tun hat. Ledigleich das Userland wurde damals übernommen (was nun aber auch schon lange her ist). Daher kannst du auch Treiber von OS X nicht für BSD nutzen. Mit Druckern, was du ja auch angesprochen hast, sieht es etwas anders aus. Für Cups gibt es, meines Wissens, tatsächlich relativ viele Treiber.
 
Hallo FreeBSD-Freunde!

Was meint Ihr dazu, oder weiß da jemand sogar genaues zu berichten, was dafür oder dagegen spricht, bzw. hat schon Erfahrungen damit gemacht, einen Treiber zu modifizieren und an FreeBSD anzupassen?

Die Frage hatte ich mir auch schon gestellt.
Es ist abhängig von der Software-Lizenz des Treibers, ob eine Anpassung überhaupt möglich ist.
Die Lizenzen sollen möglichst mit der BSD-Lizenz kompatibel sein.
 
Das mit den Treiber "Anpassungen" ist generell schon so eine Sache. Gerade jene, die durch eher empirisches Vorgehen (trial+error) oder anhand NDA-Unterlagen entstanden sind, sind einfach nicht portierbar. Da wimmelt es dann von 0xCAFE <wilderbitoperator> 0xBEEF und lauter so magic Gehampel, dass niemand nachvollziehen kann.
An gewissen vielen Enden ist das aber notwendig, um das auf die eigenen Datenschnittstellen im Kernel anzupassen.
 
post: 274199 schrieb:
Und genau da liegt der Fehler. OS X hat einen eigenen Kernel (Mach Microkernel) der nix mit FreeBSD zu tun hat. Ledigleich das Userland wurde damals übernommen (was nun aber auch schon lange her ist)...
OK, danke für die Aufklärung. Dieses Detail war mir offengestanden nicht bekannt, macht mir aber jetzt die Nichtkompatibilität verständlich. Danke Rakor für die Info.

Mit Druckern, was du ja auch angesprochen hast, sieht es etwas anders aus. Für Cups gibt es, meines Wissens, tatsächlich relativ viele Treiber.
Nun, aber auch hier findet man oftmals nur Treiber für Apple. Aber könnte man dann einen OS-X-Druckertreiber tatsächlich auch für FreeBSD und Linux benutzen?

Es ist abhängig von der Software-Lizenz des Treibers, ob eine Anpassung überhaupt möglich ist.
Die Lizenzen sollen möglichst mit der BSD-Lizenz kompatibel sein.
OK, das mit der Lizenz mag zwar schon wichtig sein, aber das was mich interessiert ist einfach mal die Möglichkeit vom technischen Aspekt her betrachtet. Daß mir aber letztendlich die Lizen dann die tatsächliche praktische Umsetzung verbieten könnten, ist wieder eine andere Problematik.
Aber ich danke Dir dennoch UlrichG, für diesen nicht unwichtigen Hinweis!

Und auch Dir double-p ein Dankeschön für die Info.
 
In einer guten Welt braucht der Drucker keinen Treiber, da er eine standardisierte Beschreibungssprache wie das gute, alte Postscript oder PCL spricht. Die Konvertierung von dem von den meisten Programmen ausgegeben Postscript in die druckereigene Sprache übernimmt, sofern sie notwendig ist, Ghostscript. Dazu kommt dann noch eine Beschreibungsdatei (die PPD-Datei, kann meist 1:1 von Windows übernommen werden), die ein paar Eigenheiten wie Abmessungen und Steuerzeichen definiert. Für das ganze braucht man eigentlich nicht mal CUPS, das lässt sich auch in ein paar Zeilen verscripten. Aber CUPS macht das Leben halt einfacher, solange es denn funktioniert...

Wenn der Drucker aber eine proprietäre Sprache spricht oder sogar auf den ekligen, inzwischen zum Glück weitgehend verschwundenen Windows NT GDI-Renderer (GDI war das Grafiksubsystem von von NT4 und NT5. Streng genommen eigentlich nur eine Bibliothek, aber das geht hier zu weit.) zurückgreift, wird es eklig. Dann ist im Treiber meist ein verkompiliertes Programm enthalten, was von Postscript in diese proprietäre Sprache übersetzt. Alles hängt dann daran, es zum Laufen zu bekommen. OS X Programme kann FreeBSD nicht ausführen, es ist einfach zu unterschiedlich. Ein ganz anderes Binärformat, ein völlig inkompatibles Framework, etc. Aber Linux-Programme bekommst du vielleicht im Linuxulator zum Laufen.
 
Ich habe vor längerer Zeit einen Artikel darüber gelesen, wie so eine Software rechtlich korrekt adaptiert wird.
Ein Entwickler studiert den Quellcode und erstellt eine Spezifikation.
Ein anderer Entwickler, der den Originalcode nicht eingesehen hat, schreibt den neuen Code anhand der Spezifikation.
So ist sichergestellt (?), daß es zu keinen Lizenzverletzungen kommt.
Es ist also eine sehr aufwendige Vorgehensweise.
Ich finde den Artikel nicht wieder, obiges aus dem Gedächtnis zusammengefaßt.
 
Herzlichen Dank Yamagi!
Deine Ausführungen sind nicht nur informativ, sondern auch jedesmal sehr ausführlich und detailliert; man merkt, daß Du Dir beim Antworten immer sehr viel mühe gibst. Ich finde, dafür sollte Dir mal ein besonderes Lob ausgesprochen werden, was ich hiermit tue!

@UlrichG:
Das ist schon sehr interessant, was sich diese Leute alles einfallen lassen, um die Lizenzprobleme zu umgehen. Aber wenn auch nur ein kleiner Teil der neuentwickelten Software dann zufällig doch mit der Originalsoftware übereinstimmt, freuen sich die Anwälte.
 
Das mit den Treiber "Anpassungen" ist generell schon so eine Sache. Gerade jene, die durch eher empirisches Vorgehen (trial+error) oder anhand NDA-Unterlagen entstanden sind, sind einfach nicht portierbar. Da wimmelt es dann von 0xCAFE <wilderbitoperator> 0xBEEF und lauter so magic Gehampel, dass niemand nachvollziehen kann.
An gewissen vielen Enden ist das aber notwendig, um das auf die eigenen Datenschnittstellen im Kernel anzupassen.

Außerdem müsste man solchen Code 1:1 kopieren,
weshalb die vielen Linux-Treiber noch nichtmal zur Orientierung dienen können (Stichwort Lizenzen).
 
Aber gibt es denn überhaupt eine Möglichkeit, ein Gerät zu betreiben, für das man keinen Treiber für FreeBSD bekommt?

...wahrscheinlich wohl nicht, außer über eine VM, oder?
 
Außerdem müsste man solchen Code 1:1 kopieren,
weshalb die vielen Linux-Treiber noch nichtmal zur Orientierung dienen können (Stichwort Lizenzen).

Mmmmh... es ist moeglich einen "Linux-Treiber" als Basis zu verwenden,
um Bottom-Half (1) Implementierung eines Treibers zu spezifizieren.

Kritisch sind das "Recycling" oder das Darstellen von Dienstelementen,
welche Bottom-half (1) bei Interaktion mit Hardware benutzt werden, wenn
diese direkt vom Treiber bzw. dem Originalimplementierung uebernommen
werden... aber da bin ich mir nicht wirklich so sicher... bin kein Jurist. :-).

Aufgrund der "Nicht-Architektur" (instabile KPI / API) bzw. der fundamentalen
Unterschiede (bspw. Dienstelemente, -primitiven, ...) des Linux-kernels zur
Architektur eines *BSD-Kernels, wird sich ein Derivat eines Linux-Treibers
sich (definitiv) als eine strukturell verschiedene Neuentwicklung manifestieren.

Aber gibt es denn überhaupt eine Möglichkeit, ein Gerät zu betreiben, für das man keinen Treiber für FreeBSD bekommt?

...wahrscheinlich wohl nicht, außer über eine VM, oder?

Wie ich es richtig verstanden habe, dreht es sich wohl (hierbei)
um einen Drucker. Persoenlich habe ich gute Erfahrungen mit
Druckern von HP gemacht.


-------------

1. Es sei angemerkt, ein Kernelmodul (bspw. Treiber) sich laut
#
# http://www.amazon.de/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=dp_ob_title_bk

im Groben in zwei Sektionen unterteilen:

Code:
 (a) Top-half, bspw. generische Komponenten von Modul, 
       die Prozessen und anderen (generischen) Komponenten 
       des Kernels Dienst erbringen

 (b) Bottom-half, bspw. HW-nahe Komponenten 
       von Modul, welche mit HW interagieren

Edit: Mein Sinn fuer Orthographie ist bei mir komplett ruiniert...
 
Ja, man könnte das natürlich tun, aber man würde sich mit den meisten Linux-Treibern wohl die GPL einfangen, weswegen ich ja auf die Lizenzen hingewiesen habe.
Dass es rein technisch gehen würde, einen solchen Treiber als Basis für die Hardwareinteraktion zu verwenden, möchte ich auch nicht in Frage stellen.
 
Ja, man könnte das natürlich tun, aber man würde sich mit den meisten Linux-Treibern wohl die GPL einfangen, weswegen ich ja auf die Lizenzen hingewiesen habe.

Inwiefern??? Also ich habe keine Erfahrung mit GPL, da ich GPL kontaminierte
Softwarekomponenten exzessiv vermeide (wenn ueberhaupt moeglich).

D. h. wenn ich eine Konstante (Befehl, Flag, ...) aus dem Linux-Treiber uebernehme,
muss dann die Neuentwicklung als GPL lizensiert werden???

Ist also GPL auch an einem vom Linux Treiber abgeleiteten Verhaltensmuster (wie
ich im vorigen Posting beschrieben habe) bzgl. Bottom-half Implementierung (in
Reimplementierung) gebunden?
 
Na ein Rechtsanwalt bin ich auch nicht ;) Aber es ging bei douple-p um "0xCAFE <wilderbitoperator> 0xBEEF und lauter so magic Gehampel, dass niemand nachvollziehen kann". Das ist dann doch mehr als nur eine einzelne Konstante, weshalb ich mir ziemlich sicher bin, dass die GPL in diesem Fall greift. Und das Problem ist ja die "virulenz", sobald du GPL-Fragmente in einen BSD-Treiber kopierst, "infizierst" du den Kernel, insofern dass du ihn unter den Bedingungen der GPL weitergeben musst, wenn der Treiber enthalten ist.

Die GPL greift, sobald du Code kopierst, und im Falle des quasi einzigen ALSA-Tutorials hat der Autor auch seine Codebeispiele unter GPL gestellt und behauptet, dass man ALSA danach nur noch in GPL-lizensierten Programmen verwenden kann… ich halte das nicht für realistisch, aber wer kann schon von sich behaupten, die juristischen Klauseln der GPL wirklich richtig zu verstehen?
 
Naja, die Gretchenfrage ist halt, was ein "abgeleitetes Werk" ist. Die GPL nutzt den Begriff zwar, definiert ihn aber nicht. Entsprechend gibt es viele Ansichten. Das eine Extrem ist, dass alles automatisch ein abgeleitetes Werk sei, was auch nur indirekt mit GPL-Code in Berührung gekommen ist. Demnach ist beispielsweise Code schon dann mit der GPL infiziert, wenn die auch nur eine im Binärcode vorliegende und unter der GPL stehende Lizenz zur Laufzeit linkst. Das andere Extrem ist, dass es praktisch keine abgeleiteten Werke gibt, da jedes Werk immer auch gleich ein neues Werk darstellt. In diesem Fall würde die GPL nie greifen. VMWare versucht zum Beispiel so im Rahmen der GPL-Klage gegen ESX (oder wie es im Moment gerade heißt) zu argumentieren. In der Praxis liegt die Wahrheit zwischen diesen beiden Extremen. Wo genau entscheidet im Zweifel ein Richter. Deshalb gilt für den vorsichtigen Entwickler: Hände weg von der GPL, solange dein Code nicht auch unter ihr steht, denn es kann dir großen Ärger machen.
 
Danke @Yamagi! D. h. sollte ich irgendmal Langeweile haben... :-).

Waere ich gut beraten (bei Treiberentwicklung) das mich Mephisto
nicht verleitet, ein von GPL lizensiertes Werk abgeleitetes Werk zu
erschaffen. :-(.

Aber eine von einem Linux-Treiber abgeleitete Spezifikation (aehnlich wie
@UlrichG es anmerkte) fuer eine Teilmenge von Komponeneten von einer
Neuentwicklung eines Treibers muesste doch sicherstellen, dass die neu
geschaffene Codebasis nicht als GPL lizensierbar sein muesste???

(Sorry fuer diese etwas sperrige Frage, es beschaeftigt mich.)
 
Aber, als ich das vor Jahren mal etwas genauer angesehen hatte, da stammte doch auch eine Menge aus GNU und ist damit unter GPL, was in FreeBSD drin ist. Ich mochte nun nicht weiter sehen und habe auch nur ein 8.4 am Laufen, aber less(1) ist ein solches Beispiel. Damals gab es auch eine Bestrebung, mehr und mehr Code neu zu schreiben um diese Abhängigkeiten los zu werden. Ob sich so etwas tatsächlich lohnt, nur weil eine andere Freie Lizenz nicht ganz der eigenen Vorstellung entspricht, kann ich schlecht beurteilen. Mir kommen diese Kämpfe mitunter wirklich unnötig vor, die es da so zahlreich gibt und ich möchte nur mal an die cdrtools von Jörg Schilling erinnern (https://de.wikipedia.org/wiki/Cdrtools), was ich als damals großen Krach noch in Erinnerung habe.

Einen echten Unterschied sehe ich eben zu geschlossenem Code, der ja meist auch proprietär ist und das ja niemals zufällig. Leute, die sich da etwas schützen wollen, muss man verstehen und ihren Wunsch respektieren.

PPD-Files sind ja wohl nie geschützt. Keine Ahnung, aber da habe ich mir gelegentlich welche aus einem GNU/Linux abgekupfert. Meist musste ich dann nur Kleinigkeiten anpassen. Im Allgemeinen bevorzuge ich aber noch immer PS-Drucker.
 
Zurück
Oben