[VDR4Arch] Kein digitaldevices-dvb-driver mehr (Paket enthält nix)

Zitat von M-Reimer

Copperhead hat zeitweise die Treiber gegen das bestehende dvbcore gebaut. Ja, es wurden dafür Funktionen rausgeworfen, aber es hat sich nie jemand über fehlende Funktionen beschwert. Können also jetzt nicht so brennend wichtig sein.

Das heißt erst mal nur, dass es bei Euch keiner gebraucht hat. Nicht, dass es generell keiner braucht.

Zitat

Außerdem kann man auch dafür sorgen, dass die Kerneltreiber die nötigen "Basisfunktionen" bereitstellen...

Kann man. Nach endlosen Diskussionen bekommst Du dann eine API-Erweiterung, die anders ist, als die, die Du wolltest. Dann darfst Du den Treiber noch entsprechend umschreiben. Gleichzeitig weisst Du, dass die realisierte API-Erweiterung nicht optimal ist.

Zitat

Hier wird immer so hingestellt als wäre es gänzlich unmöglich einen Treiber in den Kernel zu kriegen. Das ist nachweißlich nicht so.

Wer behauptet das? Natürlich ist es möglich. Es muß eben jemand machen, und dieser Jemand muß viel Motivation und Zeit mitbringen.

Zitat

Ich hätte aber ein Argument für die Hersteller, das für den Treiber im Kernel spricht: Eventuelle inkompatible Änderungen an der internen API werden, ohne das der Hersteller nochmal ran muss, üblicherweise für alle betroffenen Module direkt von den Kernel-Entwicklern umgesetzt.

So einfach ist das nicht:
Ja, die ändern etwas, ohne den Treiber zu testen und ohne Dich zu fragen. Du hast dann einen Treiber, der kompiliert. Du weißt aber nicht, ob er funktioniert!

Als Treiber-Maintainer darfst Du dann die Drecksarbeit machen: Den ganzen Mist nachtesten und etwaige Regressions fixen.

Falls Du das nicht tust, hast Du ein anderes Problem:
Nach 1/2-1 Jahr fließt der Kernel mit dem geänderten Treiber in eine Distribution ein, d.h. etwaige Fehler kommen verspätet hoch. Damit darfst Du Dich dann beschäftigen.

Das ganze mit allen möglichen Treiberversionen, denn ältere Kernel haben auch ältere Treiberstände. Seit die Kernels mit hoher Frequenz released werden, musst Du also eine ganze Reihe von Treiberständen bedienen.

Wenn Du das alles "richtig" - d.h. mit einem gewissen Qualitätsanspruch - machst, steckst Du in einem Hamsterrad. Ich habe mich entschieden, kein Hamster mehr zu sein.

CU
Oliver

der User nutzt normalerweise Windows

selbst meiner schwester die linux fürs Internet nutzt ist klar das man ab und zu hand anlegen muss und bekommt das hin.

Mir persönlich isses Wurscht ob der treiber in den kernel kommt.

Nur das Treiber auschecken dauert bei mir etwas dank dem rosa Riesen.

An sonsten ist es zumeist kein Akt den Treiber zu bauen

gut ich aktualisiere auch nicht ständig den Kernel wozu auch wenn die Kiste rennt

Zitat von Copperhead

- Man bekommt dann eingeredet, dass Treiber nicht in den Kernel gehören. (Sundtek ist da Meister). Treiber gehören unter Linux schon immer in den Kernel. Das war schon immer so und wird auch so bleiben.

Wenn du selber einen Kerneltreiber geschrieben hast und den auch für sehr viele Kunden so bereitstellen kannst das sie diesen sofort verwenden können dann können wir gerne darüber sprechen.
Wenn wir ein Geräteupdate machen sind die Treiber schon im Vorhinein verfügbar, kleine Anpassungen können wir jederzeit für alle Systeme anbieten.
Unsere Kunden verwenden teilweise noch ältere 2.6er Kernel welche sie nicht so einfach aktualisieren können.

Zudem ist das Ganze so getrimmt das es auch auf allen möglichen Architekturen läuft. Wir müssen uns um Kernel-Updates nicht kümmern.
Des weiteren kommt da demnächst noch einiges mehr, und es baut alles auf die vergangenen Entwicklungen auf.

Vom Treiber-Support her haben wir keinerlei Probleme mit unseren Kunden und das vom ersten bis zum aktuellsten Kunden, und das zählt.

Ich habe auch 2 DVB-S2 Sticks von Sundtek und nutze diese an der Dream und VDR. Mit dem Treiber gab es bisher nie ein größeres Problem und falls eines entstand wurde immer kurzfristig reagiert

Übrigens sind Sundtek-Sticks und Digital-Devices-Karten die ideale Mischbestückung. Die tun sich nämlich überhaupt nichts, schon Prinzip bedingt.

Gerald

Und wenn der nächste Hersteller auf die gleiche glorreiche Idee kommt, systemaufrufe wie ioctl, read && co per LD_PRELOAD umzubiegen, dann gibts trouble.

Das Problem ist doch das es im Linux Kernel keine echte Schnittstelle, Logik für zusätzliche Treiber gibt.

Das viele Gerätetreiber im Kernel drin sind liegt doch nur an der Historie von Linux. Diese wurde geschrieben und implementiert weil talentierte Leute Ihre Hardware zum Laufen bringen wollten und sich kein Hersteller über viel Jahre dafür interessiert hat und tatsächlich wenige bis heute tun. Einzig Intel und auch AMD haben früh angefangen Informationen für ihre CPUs einfließen zu lassen, fast alles andere kam aus "der Community".

Im Business Umfeld gibt es auch Treiber Pakete für Server mit RHEL oder SLES, aber eben vorkompiliert für exakt eine Kernelversion. Da kann man nicht links oder rechts gehen, sonst gibt's kein Support, noch gibt es ständige Kernel-Updates. Im Gegenteil, eigentlich alte Kernel werden sehr lange zelebriert. Aufgrund der Verbreitung von RHEL und SLES ist vmtl. die Version 2.6.32 bis heute noch die am meisten installierte Kernel Version ...

Und wer schon mal mit den zwei LinuxTV Pappnasen von RedHat, Mauro Carvalho oder Jared Wilson, zu tun hatte, würde UFO ziemlich gut verstehen, da schwillt die Halsschlagader aber ziemlich schnell.

Regards
fnu

fnu: das ist ein super interessantes Thema, aber in diesem Thread zu antworten würde den Thread sprengen und wäre nicht im Sinne des Threaderstellers.

Zitat von fnu

Das Problem ist doch das es im Linux Kernel keine echte Schnittstelle, Logik für zusätzliche Treiber gibt.

Die benötigt Linux auch nicht. Es ist ein monolithischer Kernel. Treiber gehören in den Kernel!

Zitat von fnu

Das viele Gerätetreiber im Kernel drin sind liegt doch nur an der Historie von Linux.

Historie? Vielleicht. Linus hat den Kernel eben monolithisch entwickelt.
Du darfst dir gerne einen anderen Kernel suchen. Vorzugsweise einen Microkernel. Kannst ja mal sehen, wie weit du mit Minix oder GNU/Hurd kommst.

Zitat von fnu

Im Business Umfeld gibt es auch Treiber Pakete für Server mit RHEL oder SLES, aber eben vorkompiliert für exakt eine Kernelversion.

Das sind dann Closed Source Kernelmodule. Das wird leider immer noch geduldet.

Zitat von fnu

Und wer schon mal mit den zwei LinuxTV Pappnasen von RedHat, Mauro Carvalho oder Jared Wilson

Mit Jarod Wilson hatte ich noch nicht das Vergnügen.
Mauro Carvalho Chehab finde ich sehr sympathisch.

Zitat von wirbel

er auf die gleiche glorreiche Idee kommt, systemaufrufe wie ioctl, read && co per LD_PRELOAD umzubiegen, dann gibts trouble.

Nein selbst das ist kein Problem da man diese Dinge Chainloaden kann.
Ausserdem kann man wie schon tausend mal erwähnt direkt auf den Treiber zugreifen, es ist nur ein Kompatibilitätslayer, wenn man direkt drauf zugreifen möchte wird's nicht benötigt. Dann linkt man die Applikation einfach gegen libmediaclient.so; noch direkter geht's mit libmcsimple.so wo die Befehle direkt mit net_* Prefixen ausgewiesen sind. Also alles kein Problem mit sehr vielen Freiheiten.

Zitat von Copperhead

Die benötigt Linux auch nicht. Es ist ein monolithischer Kernel. Treiber gehören in den Kernel!

Das ist BS, die Schnittstellen wurden ja im Linux Kernel implementiert damit man sie auch nutzt. Oder warum denkst du gibt es diese Schnittstellen - noch dazu sind sie mit voller Performance ausgestattet.
Zudem gibt's auch VFIO damit man PCI/e mit DMA in den Userspace bringen kann, es gibt denke ich sogar gewisse Treiber die im Userspace damit eine bessere Performance bringen (nachzulesen auf der LKML).

Zitat von Sundtek

Nein selbst das ist kein Problem da man diese Dinge Chainloaden kann.
Ausserdem kann man wie schon tausend mal erwähnt direkt auf den Treiber zugreifen, es ist nur ein Kompatibilitätslayer, wenn man direkt drauf zugreifen möchte wird's nicht benötigt. Dann linkt man die Applikation einfach gegen libmediaclient.so; noch direkter geht's mit libmcsimple.so wo die Befehle direkt mit net_* Prefixen ausgewiesen sind. Also alles kein Problem mit sehr vielen Freiheiten.

Ganz ehrlich, das will wirklich niemand. Erst recht keine Linux-Distries.
Userspace Apps verlinken mit closed-source third-party libs.

Mal ganz ehrlich, ich finde euren Support Klasse und eure Hardware funktioniert wirklich gut.
Und ich würde liebend gern eure DVB-Sticks selbst nutzen, noch dazu da ihr keine 5km Luftlinie von mir entfernt seid.
Das wäre mir auch den saftigen Preisunterschied zu den gleichwertigen Asia Produkten wert.

Aber eurer closed-source Treiber-Modell ist für mich ein absolutes No-Go. Ich verstehe ja auch, warum ihr das immer versucht schön zu reden.

Der einzige Grund, warum ich den Sundtek-Treiber noch nicht direkt anspreche, ist, dass ich quasi cDvbDevice komplett klonen müsste. Das war bisher zu viel Aufwand. Aber vielleicht finde ich ja mal Zeit, so dass der vdr direkt mit dem Treiber spricht.

Lars

Willst du für jeden Treiber eine eigene Software schreiben? Wozu gibt es dann definierte Schnittstellen?

Evtl. bekomme ich den vdr ja auch minimal so gepatcht, dass sich userspace-Treiber besser einbinden lassen.
Es würde ja quasi Funktionspointer für ein paar Aufrufe reichen.

Lars

Zitat von UFO

Kann man. Nach endlosen Diskussionen bekommst Du dann eine API-Erweiterung, die anders ist, als die, die Du wolltest. Dann darfst Du den Treiber noch entsprechend umschreiben. Gleichzeitig weisst Du, dass die realisierte API-Erweiterung nicht optimal ist.

Sobald man mit mehr als einer Person an einem Projekt arbeitet muss man zwangsläufig Kompromisse eingehen...

Zitat

Nach 1/2-1 Jahr fließt der Kernel mit dem geänderten Treiber in eine Distribution ein, d.h. etwaige Fehler kommen verspätet hoch. Damit darfst Du Dich dann beschäftigen.

Distributionen, die einen "alten Kernel" dann ewig verwenden, die liefern aber meist auch Bugfixes an "externen Treibern" nicht aus. Hier werden nur echte Sicherheitslücken manuell in die vorhandene Version gepatcht.

Mir solls letztlich egal sein. Wenn aber jeder so denken würde, dann wäre ein "komfortables" Linux (anfängerfreundlich) unmöglich. Woher soll denn der Anfänger wissen, dass ihm ein Treiberpaket fehlt? Und das dann für jeden Kleinkram von Netzwerkkarte bis zur Maus?

Zitat von wirbel

Willst du für jeden Treiber eine eigene Software schreiben? Wozu gibt es dann definierte Schnittstellen?

Dafür kann man Plugins erstellen, für tvheadend haben wir das bereits getestet, es wurde auch angenommen aber wir müssen den Patch noch einmal aktualisieren. Ein Plugininterface ist sehr einfach zu realisieren ausserdem läuft das auch auf Android ohne das man dort Administratorrechte benötigt um die Treiber zu installieren.

Zitat von wirbel

Ganz ehrlich, das will wirklich niemand. Erst recht keine Linux-Distries.
Userspace Apps verlinken mit closed-source third-party libs.

Und damit liegst du komplett falsch, wir haben mehr als genug Kunden die das anwenden, insbesondere Industriekunden benötigen jahrelangen Support und langfristige Liefergarantien.
Dort wird das Binary ausgetauscht und die nächste Geräteserie eingesetzt und fertig, niemand setzt sich dort noch hin und baut einen Treiber extra für die verwendete Kernelversion das wäre absolut
nicht ökonomisch (oder direkt gesagt absolut verrückt).

Wir wollen auch nicht direkt in die Linux Distributionen, der Grund ist einfach wenn wir ein Update fahren dann sollen die Kunden direkten Zugriff darauf haben. YaVDR hat das soweit ganz gut gelöst mit den 0-Day Updates, bei OpenElec gibt's einen Punkt im Plugin damit man den Treiber via XBMC Menü aktualisieren kann. Alle Synology NAS Systeme werden supportet ohne das wir da irgendetwas spezielles beachten müssen, selbst wenn die eine neue DSM Version rausbringen kann uns das egal sein denn es läuft ja wie es ist.
Die Installationsroutinen sind seit ca 5 Jahren gleich, es ist ein Kinderspiel die Treiber zu aktualisieren und es dauert auch nur 10 Sekunden auf egal welchem System (die Anzahl der Treiberdownloads nach einem Treiberupdate
zeigen auch dass das sehr gerne von unseren Kunden angenommen wird).

Aber jetzt wieder zurück zum Thema, und haltet uns davon raus - bei uns läuft es halt etwas anders und es hat genau so seine Berechtigung. Es gibt ja auch sehr wenige Treiberdiskussionen bei uns da es ja läuft wie es ist und praktisch keine Probleme bereitet.

Ich krame das nochmal aus.

Viele die mich etwas besser kennen wissen, dass ich es nicht gerne habe, wenn ich Unrecht habe. (Naja, wer hat das schon wirklich gerne)
Ich finde aber auch, dass es zum guten Benehmen gehört offen darauf hinzuweisen, wenn man dann doch mal nicht Recht hatte.

Also: Aus Trotz habe ich mir eine DVBSky S952 V3 bestellt um meine Cine S2 V6 außer Betrieb zu nehmen. Im Nachhinein betrachtet war das keine so übermäßig schlaue Idee.

Ich habe die DVBSky Karte also eingebaut und die funktioniert auch erstmal ganz gut. Danach habe ich den VDR ausgeschaltet und ihn gut 3 Stunden später wieder eingeschaltet, woraufhin die Karte nur noch Pixelmüll fabriziert. Ich habe also den Strom abgezogen, wieder hochgefahren und dann lief wieder alles. Knapp 24 Stunden später, fahre ich den VDR wieder hoch und abermals Pixelmüll. Zusätzlich musste ich noch feststellen, dass zwei meiner Aufnahmen fehlgeschlagen sind. (Die Einzigen zwei in diesem Zeitraum)

Zusammengefasst muss ich dann doch eingestehen, dass der Preis einer Digital Devices Karte wirklich gerechtfertigt ist. Vor allem, wenn man eine Karte benutzen will, die wirklich durchgehend fehlerfrei arbeitet.
Die Art und Weise, wie die Treiber vertrieben werden mag mir nicht gefallen, alles rumgestänkere hilft aber auch nichts. Für VDR4Arch werde ich mir einen Weg über media-build-experimental suchen. Ob DKMS oder vorkompiliert weiß ich noch nicht. Vielleicht auch nur für den LTS Kernel.

Ich dachte, ich wüsste es besser und wurde schmerzlich eines Besseren belehrt.