Aktuelles Linux Thema Treiber Frame work

S

s705081

Active Member
Hallo *,

kleine Frage große Wirkung (zweideutig!).

Was spricht aus FreeBSD sicht gegen ein Treiber Frame Work, wie es Japanische OSDL Mitglieder sich für Linux Wünschen.

Grundsätzlich wäre das doch erst mal Wünschens wert, oder gibt es dann nur Nachteile?

Link: http://www.golem.de/0511/41474.html

Gruß neo

PS: Bitte Sachlich Argumentieren!
 
Ich denke bei FreeBSD spricht nichts dagegen. Vor allem wenn das funktionierende Treiber zur Folge hätte. Wenn die Schnittstelle ausgereift ist könnte man sie sogar Release übergreifend verwenden, so dass man mit FBSD 6, 7 und weiteren den gleichen Binärtreiber verwenden kann.
 
Das Release Übergreifende ist genau das was mich interessieren würde auch das man Treiber als separaten Task (im UserMode) laufen lassen kann. Auch die Einbindung von Windows Treibern wäre wünschenswert.

Ist jetzt mal nur eine Idee.

Gruss neo
 
Soweit ich das verstanden habe wünschen die sich kein Framework, sondern in erster Linie eine stabile API.

Was es bei Linux nicht gibt, gibt es bei FreeBSD schon lange. Wir haben sogar eine stabile ABI! Das ganze nennt man STABLE (-Branch) :)

Male

P.S. Ich persönlich halte Binärtreiber für einen GPL Kernel für illegal SCNR
 
Was sie wollen ist eine API die nicht innerhalb eines branch stabil bleibt, sondern über Jahre. Will heißen, man sollte es so wie einen COMPAT Modus bauen, der über alle Branches hinweg immer die gleiche API zur Verfügung stellt.
 
Stimmt su hast recht, bleibt denn die API auch bei Version 7 zu 6 zu 5 Kompatibel? darum geht es ja hauptsächlich.

Gruss Neo
 
Nein, die API bleibt nicht zwischen 5, 6, 7 stabil. Das kann sie auch gar nicht, weil du ja neue features einbauen willst, die irgendwann zwangsläufig API-Änderungen erfordern. Wenn du das nicht machen würdest, dann wärest du auf alle Zeit verdammt auf der Stelle zu bleiben, das geht so nicht.

FreeBSD macht dies für meinen Geschmack bereits exzellent, ich sehe für BSD allgemein keinen Änderungsbedarf. Daran würden frameworks (eines würde nicht reichen btw) auch nichts ändern. Denn wenn du einen zusätzlichen Layer einführst dann müßtest du den auch irgendwann ändern, du hättest das Problem nur verlagert.

Die Kritik der Hersteller richtet sich gegen zwei Punkte:
1. Versuch der GNUschisten durch GPL-Zwang die Offenlegung von code zu forcieren. Das geht uns hier aber nichts an, die GNUschisten haben ihre Lizenz, wer da mitspielen will soll sich daran halten.

2. Das ständige Chaos von Treibern, die in Version 2.6.8.1 im Red Hat-Kernel laufen und beim Kernel 2.6.9.2 im Suse-Kernel nicht mehr. Das man da als Hardware-Lieferant das Kotzen bekommt ist nun nicht weiter erstaunlich. Aber an diesen Verhältnissen wird sich imho nichts ändern, wie man am Beitrag von Greg Kroah-Hartmann schon sieht. Geht uns aber auch nichts an als BSD'ler.
 
Wenn man seinen Kernel mit COMPAT4X baut, kann man dann 4er (Binär-)Module unter 6x laufen lassen?
 
Daniel Seuffert schrieb:
Nein, die API bleibt nicht zwischen 5, 6, 7 stabil. Das kann sie auch gar nicht, weil du ja neue features einbauen willst, die irgendwann zwangsläufig API-Änderungen erfordern. Wenn du das nicht machen würdest, dann wärest du auf alle Zeit verdammt auf der Stelle zu bleiben, das geht so nicht.
Zum Vergrößern anklicken....

Da stimme ich dir zu. Das ist sicher nicht in meinem Sinne.

FreeBSD macht dies für meinen Geschmack bereits exzellent, ich sehe für BSD allgemein keinen Änderungsbedarf. Daran würden frameworks (eines würde nicht reichen btw) auch nichts ändern. Denn wenn du einen zusätzlichen Layer einführst dann müßtest du den auch irgendwann ändern, du hättest das Problem nur verlagert.
Zum Vergrößern anklicken....

Sicher muß man an der "HAL" schicht mal was ändern aber man kann durch so eine Schicht trozdem kompertibel bleiben.

Die Kritik der Hersteller richtet sich gegen zwei Punkte:
1. Versuch der GNUschisten durch GPL-Zwang die Offenlegung von code zu forcieren. Das geht uns hier aber nichts an, die GNUschisten haben ihre Lizenz, wer da mitspielen will soll sich daran halten.
Zum Vergrößern anklicken....
Free* steht ja auch für Frei!

Ich will nicht die Grundsätze ändern sondern nur Anregungen/Denk anstöße geben um mal über andere Konzepte nach zudenken. Es gibt viele stellen wo ich ein Unix, so wie es heute ist, als veraltet ansehe. Wo man andere Konzepte haben könnte oder auch andere Techniken einsetzen sollte. Grade was die Struktur betrifft die man auf dem File System findet. Im Allgemeinen betrifft es erst mal Desktop Systeme.

Mein Gedanke zu einem HAL würde über eine System übergreifende API gehen die eine eigene "Firmware" konzipiert so das man z.b. den gleichen Treiber unter OS X, *BSD, von mir aus auch Windows nutzen könnte. Also wie gesagt es ist nur eine idee... .oO(*grübel*)

Gruss neo
 
Naja, ich versteh die Aufregung schon, aber anderseits halte ich nicht viel von Binärtreibern - und zwar jetzt nicht wegen GPL oder sonst was für Lizenzen, sondern weil der Hersteller der Hardware nach Abkündigung des Produktes nicht wirklich mehr Interesse hat, Treiber zu pflegen.
Das Problem kennt man ja schon unter Windows: für eine aktuelle Creativekarte gibt es nicht mal Treiber für ältere Windows, Treiber für diverse Hauppauge Karten sind buggy ohne Ende, wenn man Pech hat, kriegt man nie einen vernünftigen usw.

Ich verstehe die Hersteller auch nicht: sollen einmal einen Treiber im Source releasen, von mir aus mit ner Klausel, das es keine Garantie gibt und so, und schon kann man einen Großteil des Supports auf Programmierer abwälzen ohne dafür zu blechen.

Aktuelles Beispiel sind zum Beispiel Programme rund um DVB unter Windows: das was da mitgeliefert wird, ist einfach nur Schrott, aber wenigstens haben es hier ein paar Freizeitprogrammierer geschafft, was ordentliches zu bauen (bestes Beispiel: habe ein Programm gesehen, was Premiere aufnehmen kann inklusiver aller Tonspuren, der Clou an dem Proggi ist: man kann es auch streamen und so im Heimnetz verteilen, als Client reicht vlc aus ;) )

marty
 
marty schrieb:
Aktuelles Beispiel sind zum Beispiel Programme rund um DVB unter Windows: das was da mitgeliefert wird, ist einfach nur Schrott, aber wenigstens haben es hier ein paar Freizeitprogrammierer geschafft, was ordentliches zu bauen (bestes Beispiel: habe ein Programm gesehen, was Premiere aufnehmen kann inklusiver aller Tonspuren, der Clou an dem Proggi ist: man kann es auch streamen und so im Heimnetz verteilen, als Client reicht vlc aus ;) )
marty
Zum Vergrößern anklicken....

Ich gebe dir vollkommen Recht was die Pflege von Treibern für ältere Produkte angeht, aber du lieferst gerade unfreiwillig ein Musterbeispiel dafür, warum Hersteller ihre Sourcen bzw. Specs nicht freigeben wollen... Premiere will Doppelkarten vertreiben, das was du aufführst läuft den ureigensten Interessen z.B. von Premiere fundamental entgegen. Nur mal so am Rande...
 
@Daniel Seuffert: ist mir schon klar das Premiere nicht gerade begeistert ist, das man aufnehmen kann, aber Streaming in Netz würde wohl eh nur bei Leuten gehen, die einen gescheiten Upload zur Verfügung haben (das erinnert mich jetzt wieder an das Geschrei im heise Forum und die Antworten darauf, das man dann doch SDSL nehmen sollte ;) )

Mich wundert es eh, das alle Welt auf Gedeih und Verderb alles in den PC bringen will und sich dann wundert, das kopiert wird wie blöd. Die einzigen, die das meiner Meinung nach kapiert haben, sind Nintendo. Diese Gamecube Disks sind absolut kein Standart und Geräte zum Beschreiben haben wohl nur die Entwicklungsstudios.

Aber gut, das wird OT, ich hör auf.

marty
 
Den Grund kann ich dir nennen: Featuritis, es wird gepimpt bis die Schwarte kracht, egal ob es Sinn macht oder nicht. VoIP mal als aktuelles Beispiel, man muß nur einen hype entfachen und schon geht es los.

Handies sind ein weiteres Musterbeispiel, und wenn das interface für den Nutzer auch völlig ungeeignet ist (Tastaur, Winzigdisplay), man muß es pimpen bis zur bitteren Neige, Kamera, mp3-Player, Organizer, Radio, Wap, Spiele usw inklusive. Und dann kommt auch gleich der nächste Wahn: Linux und alle anderen OS müß auch gleich aufs Handy inklusive GPL, Java, Flash usw. Komplexität erzeugen, welche von 95% der Nutzer nicht gebraucht wird aber alle tragen die Kosten, den Stromverbrauch, die Sicherheitslücken usw. usf.

Das ist ein typisch menschliches Problem: Bloaten ist ein ureigenstes Bedürfnis des Menschen, wer das am besten befriedigt hat bessere Absatzchancen und verdient potentiell mehr Geld.

Aber back to topic:
HAL und Sinn bzw. Unsinn dessen. Der OP bringt eine interessante Fragestellung auf, die m.E. nicht ganz simpel beantwortet werden kann. Ich sehe einige Vorteile darin, aber auch einige Nachteile. Der größte Nachteil ist für mich ungeachtet aller potentiellen technischen Probleme die erforderliche menpower zur Umsetzung nebst der Unwilligkeit der hardware-Lieferanten sich daran zu beteiligen. Grundsätzlich will der OP ja die Attraktivität von BSD für hw-Hersteller erhöhen proprietäre Treiber zu schreiben. Das scheitert aber imho am mangelnden Willen der Hersteller vordergründig, das ist eine direkte Folge des Verbreitungsgrades von BSD in manchen Marktsegmenten (RAID-controller z.B. wäre wieder eine Ausnahme). Wenn man die Attraktivität von BSD erhöhen will muß man die Marktanteile ausbauen. Steigende Nutzerzahlen bedingen indirekt eine grössere Anzahl von contributors welche wiederumg zu einer steigenden Anzahl von committern führt. Damit wären beide Seiten des Problems positiv bearbeitet...
 
Die Grenzen der Ideologie

N'abend!

Eigentlich ist diese Diskussion mal wieder ein schönes Beispiel dafür, wie sehr die geheiligten Prinzipien der open source Bewegung den meisten Verbraucher am A... vorbei gehen dürften.

Betrachten wir den typischen PC-Benutzer: Was nutzt ihm ein Quellcode? Richtig: Nix! Denn die allermeisten Nutzer haben weder Zeit, noch Bock, noch die Kenntnisse, Code überhaupt zu lesen. Man kann seine Software also getrost als Binary auf den Markt werfen. Der Kunde wird nichts vermissen. Für den Verbraucher zählt bei der freien Software nur eines, nämlich, dass sie kostenlos ist.

Was die Unternehmen angeht: Auch in Treibern steckt Entwicklungsarbeit! Nvidia stellt ja auch nicht die Interna der Entwicklungsabteilung ins Netz, nur damit Konkurrent ATI die gleichen Fehler nicht nochmal zu machen braucht und seine Produkte früher an den Markt bringen kann. Das Schreiben von Software ist eine Dienstleistung wie andere auch. Es gibt volkswirtschaftlich gesehen keinen Grund, dafür kein Geld zu verlangen!

Treiber unter die GPL zu stellen würde den Firmen nur Nachteile und den Verbrauchern keinerlei Vorteile bringen!
 
@thorsten1: ok, das sehe ich ein, aber spätestens, wenn der Hersteller das Produkt nicht mehr vertreibt und auch kein Interesse mehr hat, sich weiter darum zu kümmern, könnte der Treiber ja offen gelegt werden

aber als Nutzer alternativer Betriebssysteme hat man sich eh dran gewöhnt, nur Hardware zu kaufen, die unterstützt wird

marty
 
thorsten1 schrieb:
N'abend!
Was die Unternehmen angeht: Auch in Treibern steckt Entwicklungsarbeit! Nvidia stellt ja auch nicht die Interna der Entwicklungsabteilung ins Netz, nur damit Konkurrent ATI die gleichen Fehler nicht nochmal zu machen braucht und seine Produkte früher an den Markt bringen kann. Das Schreiben von Software ist eine Dienstleistung wie andere auch. Es gibt volkswirtschaftlich gesehen keinen Grund, dafür kein Geld zu verlangen!

Treiber unter die GPL zu stellen würde den Firmen nur Nachteile und den Verbrauchern keinerlei Vorteile bringen!
Zum Vergrößern anklicken....

1. Geht es hier nicht um Treiber unter GPL, sondern um HAL in BSD, speziell FreeBSD, Diskussionen über GPL-Trieber bitte ich in Linux-Foren zu führen.
2. Wer glaubt, daß ATI nicht exakt weiß, was bei NVidia abläuft oder umgekehrt hat keinerlei Ahnung von dem, was hinter den Kulissen abgeht...
3. Es gibt keinen volkswirtschaftlichen Grund kein Geld für Softwareentwicklung zu verlangen. Exakt dies tut auch jder hardware-Hersteller, weil der verlangt btw. Geld für seine Produkte.
4. Jeder hardware-Hersteller dieser Erde kann Geld sparen, wenn er die specs seiner Produkte offenlegt und die Treiberentwicklung der community überlässt, es gibt genug Beispiele hierfür.
5. Die direkte Nutzung irgendwelcher Kenntnisse durch andere Hersteller scheitert meist sowohl an zu schnellen Produktzyklen als auch Patent- bzw. Softwarepatentproblemen.

Ansonsten kann ich deine Ausführungen zu Verbrauchern bestätigen, denen ist es tatsächlich völlig Banane, Hauptsache kostenlos, ob gesaugt, illegal kopiert oder sonstwas. Und was binaries anbetrifft verfolgt ja gerade FreeBSD im Gegensatz zum Beispiel zu OpenBSD eine sehr pragmatische Politik, welche bis zu Project Evil geht, weiter kann man das Spiel imho nicht mehr treiben. Das NDIS z.B. auch zu finden ist in Linux bzw. ATI und NVidia trotz der lizenzrechtlichen Bedenken verwandt werden zeugt davon, daß auch dort Kompromisse gemacht werden.

So aber nun hurtig wieder zurück zum Thema:
Ist eine zusätzliche HAL sinnvoll oder nicht und wenn ja unter welchen Prämissen.
 
[LoN]Kamikaze schrieb:
Wenn man seinen Kernel mit COMPAT4X baut, kann man dann 4er (Binär-)Module unter 6x laufen lassen?
Zum Vergrößern anklicken....

Nein, COMPATnx ist afaik nur für Userland Programme.

Off-Topic:
Ich finde, dass ein typischer Nutzer mehr hat als nur kostenlose Software. Da wäre z.B. der schon genannte bessere Treibersupport. Und es ist auch ein wohliges Gefühl zu wissen, dass man wissen könnte was sich auf dem eigenen PC abspielt. Und, dass man jemanden bezahlen könnte wenn man spezielle Treiberwünsche hat, etc etc.

On-Topic:
Ich finde FreeBSD braucht keine Veränderung in dieser Hinsicht, das Branch-System wie es momentan ist finde ich sehr Benutzer- und auch Businessfreundlich. :)
 
Daniel Seuffert schrieb:
2. Wer glaubt, daß ATI nicht exakt weiß, was bei NVidia abläuft oder umgekehrt hat keinerlei Ahnung von dem, was hinter den Kulissen abgeht...
4. Jeder hardware-Hersteller dieser Erde kann Geld sparen, wenn er die specs seiner Produkte offenlegt und die Treiberentwicklung der community überlässt, es gibt genug Beispiele hierfür.
Zum Vergrößern anklicken....

Wer glaubt, dass man anhand der Specs, die man fuer einen Treiber braucht, die
internas der HW "einfach mal so" nachbauen kann, der sollte lieber mal ganz
leise sein.
Effektiv reden wir hier von einer (erweiterten) ABI Beschreibung.

Ich halte HAL und dann irgendwelchen Binaer-Schrott-Modul-Krams fuer Bloedsinn.
 
Ich bin eigentlich schon für funktionierende Treiber, aber wenn die nur in Binärform (und möglicherweise noch proprietär) sind, hab ich was dagegen.
Ob FreeBSD jetzt so ein Framework braucht/hat/bekommt/..., ist mir momentan noch egal. Solange das System läuft find ich das in Ordnung, für eine genauere Einschätzung fehlt mir die (Programmier-)Erfahrung - das geb ich ganz ehrlich zu :)
 
Mich würd da mal was interessieren:
Warum macht man eigentlich nicht gleich den ganzen Schritt und führt (zumindest für alle Unix-artigen Systeme) eine Norm ein, die die Schnittstelle von Treibern und Programmen zum OS festlegt. Sonst wird ja auch alles genormt. Die Schnittstelle meiner GraKa zum Monitor ist genormt, die Art der Steckkontakte der einzelnen Hardwaresachen auf dem Mainboard ist genormt, die Steckdose in der Wand ist genormt.
Nur bei der Software macht jede Firma was sie will?! Programme tun doch auf allen Plattformen das gleiche: Fenster aufmachen, Datei laden, Maus- und Tastatureingaben verarbeiten, Dateien speichern, usw. Wenn's überall so zuginge wie im PC-Markt hätte jede Automarke ein eigenes Tankstellennetz! Warum gibts noch nicht einmal die Bestrebung, zu einer Norm zu kommen?
Was meint ihr dazu?
 
Eine Norm gibt es bereits in Form von POSIX nebst den anderen Normen von RFCs über IEEE-Normen bis weiß der Himmel was.

Und wie bitte lieber Thorsten willst du sämtliche unoxiden Betriebssysteme mit hunderten von Filesystem, unterschiedlichsten Schnittstellenanforderungen, unterschiedlichen Architekturen (Prozessor, Busse usw) von der Grafikkarte bis hin zum USB-device in einen Standard pressen? Und das dann auch noch für längere Zeiträume? Und wer soll die hardware-Lieferanten zwingen einheitliche devices herzustellen, die genehmigt sind? Und was machen wir, wenn Firma X morgen meint, sie müsse einen neuen Prozessor, Bus, irgendwas auf den Markt bringen, für die es keinen Standard gibt, kommt dann die Interpol und verhaftet die? Und wer legt den Standard auf welcher Ebene fest? Einigung auf dem kleinsten gemeinsamen Nenner? Und was machen wir mit den zusätzlichen Funktionen, die im Produkt X von Hersteller Z implementiert sind? Lassen wir die unter den Tisch fallen?

Ganz nette Idee so ein Unified driver model, one size fits all, kommt auch alle Jahre wieder auf, bringt aber herzlich wenig in der Praxis.

Und wenn wir grade beim Auto sind, warum gibt es eigentlich kein Norm für Motoren oder sowas, das ist doch das zentrale Teil im Auto. Warum kann ich eigentlich nicht den guten Ford-Motor in meinen Mecredes einbauen? Warum braucht eigentlich jedes Auto ne andere Kupplung oder Getriebe? Und wieso sehen die alle anderes aus? Warum haben die nicht alle die gleiche Farbe, Henry Ford hat das Modell T ja anfangs auch nur in schwarz rausgebracht? Und wieso hat MS dann mehrere OS mit unterschiedlichen Treibermodellen im Sortiment? Wieso läuft eigentlich mein OS nicht ohne Änderungen vom Handy bis hinaus zum 10.000-Prozessoren-cluster?

Tja, Fragen über Fragen, die Welt scheint doch nicht so einfach zu sein...
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben