Die Fehler kannst du beheben indem du den Parameter dev einfach beim typ den präfix class_ löschst.
Gibt noch ein paar mehr Stellen, einfach nach class_<irgendwas> ausschau halten und löschen.
Dann kompilierts aber mit ein paar Warnings.
Jedoch geht bei mir insmod dvbloop.ko nicht -->
insmod: error inserting 'dvbloop.ko': -1 Unknown symbol in module*edit* funktioniert doch, musste nur dvb-core.ko zuerst laden (hab keine dvb karte drin)
gruss
Leute, es hindert Euch doch keiner daran, so eine Lösung zu bauen.
Also was habe ich gemacht?
Ich habe einfach einen aktuellen snapshot aus dem hg-repos genommen, alles rausgeschmissen bis auf dvb-core und meine angepassten dvbloop-Quellen hinzugefügt. Fertig.
Ich hatte arge Schwierigkeiten den "normalen" aktuellen Snapshot, meine angepassten dvbloop-Quellen und dann die auch vorhandenen (DVB)Kernel-Header unter einen Hut zu bringen. Ich konnte die Module hinterher nicht laden, weil nix zueinander passte.
Das Problem ist also:
a) Ich habe einen Kernel mit Kernel-Header installiert, der eine alte DVB-API mitbringt
b) Ich habe einen aktuellen S2API Snapshot, den ich separat mit den a) kompilieren kann, weil das Makefile dies irgendwie bewerkstelligt, obwohl im Kernel ja auch schon DVB-Includes sind
c) Ich habe das angepasste dvbloop-Modul, dass sich auf b) beziehen soll und von a) nichts sehen soll.
d) Ich bin kein Makefiles-Experte und weiß nicht, wie ich das bewerkstelligen soll, um c) zu erreichen. Darum habe ich es so gemacht, wie es jetzt gerade ist. Nicht schön, ich weiß.
Eine "Experte" müsste sich mal anschauen, wie ich die originalen dvbloop-Quellen gegen einen zusätzlichen Snapshot kompilieren kann und _NICHT_ gegen die im Kernel enthaltene DVB-API. Ist vermutlich nicht schwer. Ich kann es nicht.
Alles klar? 
Für das original dvbloop wäre das wohl kein Problem aber wenn ich das richtig verstanden habe, dann wurde das von RMM für den Netceiver modifiziert und um auch DVB-S2 ohne multiproto und S2API zu können wurden dafür einige "dirty tricks" benutzt, die 100%ig rejected werden.
Selbst wenn man jetzt dvbloop nicht nur für S2API anpaßt (im Sinne von zum Laufen bringen) sondern sauber nach S2API portiert, dann würden vermutlich die Userspace Programme (mcli?) nicht mehr funktionieren, d.h. solch eine Portierung kann nur RMM selbst machen.
Ich bin gerade dabei dvbloop mit den hier vorgeschlagegen Änderungen (class etc) in den aktuellen dvb-tree zu mergen und erstelle dann nachher mal ein diff...
Edit:
dvblo: dvblo_init(): successfully initialized DVB Loopback Adapter Version 0.9.4-s2api
diff kommt gleich
Irgendwie habe ich ein paar Probleme mit meinem dvb-tree, beim diff gegen das was ich fuer das original gehalten habe kommen 18mb raus, soviel habe ich aber wirklich nicht geaendert...
dvbloop hat nichts mit S2 zu tun, die dirty tricks sind gar nicht programmiert sondern "nur" Konvention. Das ist gerade der Witz an der RMM-S2-Lösung, dass bis auf den eigentlichen Tunertreiber (zB. mcli...) niemand davon wissen muss. Es gibt nur ein paar neue FECs und die S2-Modulationen werden in den oberen 16Bit der FEC übertragen (getunnelt...). Der dvbcore und nicht S2-aware Programme merken davon nichts. Sicher ist es ein Hack, aber wenigstens einer, der ohne grosse Nebenwirkungen funktioniert 
Das Problem mit dem dvbloop ist eher was anderes: Es erlaubt "legal" ohne "Kernel tainted" etc. binary-only Tunertreiber im Userspace, eben zB. wie den mcli (noch). Und das ist aus Kernel-Entwickler/OSS-Sicht natürlich sehr ungern gesehen. Der Rechberg hat mit seinen em*-Treibern ja sowas ähnliches gemacht und sich damit ziemlich in die Nesseln gesetzt.
ZitatIch bin gerade dabei dvbloop mit den hier vorgeschlagegen Änderungen (class etc) in den aktuellen dvb-tree zu mergen und erstelle dann nachher mal ein diff... Edit: dvblo: dvblo_init(): successfully initialized DVB Loopback Adapter Version 0.9.4-s2api
Das klingt vielversprechend 
diff her
Hmmm,
ich laufe hier leider auch nur im Kreis
ZitatEdit:
dvblo: dvblo_init(): successfully initialized DVB Loopback Adapter Version 0.9.4-s2api
wenn hier was kommen würde bzw.
wenn real_schorsch hier helfen könnte dann hätte man ja mal eine Chance
den NetCeicer unter dem Kernel 2.6.28 endlich mit der HDe unter einem
VDR 1.7x zu betreiben.
Grüße
cinfo
Hallo ihr,
Zitatwenn hier was kommen würde bzw. wenn real_schorsch hier helfen könnte dann hätte man ja mal eine Chance
Hmm.. also so wie ich das sehe, fehlt doch gar nicht mehr viel....
Wir haben doch nun festgestellt:
a) das dvbloop-s2api hier braucht Anpassungen wegen dem Kernel 2.6.28
b) das dvbloop-s2api hier ist (wenn auch auf S2API angepasst) auf einen etwas anderen v4l abgestimmt als er im 2.6.28 steckt
(stichwort: inkompatilität des dvb-core moduls). ob das ding nun nen eigenen dvb-core baut oder nicht wäre ja letztlich wurscht, solange das gebaute dvb-core modul kompatibel/das gleiche zum 2.6.28 dvb-core wäre...
Nun zu a)
das wäre ja inzwischen schon besprochen/gefixed hier. die nötigen änderungen sind gepostet....
Was fehlt ist b), also die Kompatibilität zum restlichen v4l-Treiber, so wie er im 2.6.28 ist... da das Paket hier schon auf die S2API abgestimmt ist, kann da doch nicht so viel zu drehen sein? Maximal ein Einbau der Änderungen von ein paar Wochen HG-Stand...?
Aber sorry, stecke nicht tief genug in der dvbloop&v4l Materie um hier weiter helfen zu können 
Ich würde jedenfalls mögliche Integrationspatches in den 2.6.28 v4l hier sofort testen
grüße
Entschuldigt die Verspätung ich habe es nachmittags nicht mehr hinbekommen und abends hatten wir Besuch...
Jaja, einfach mal ein "make distclean" drüberlaufen lassen und schon sieht alles ganz anders aus...
Anbei ein Patch gegen einen halbwegs aktuellen dvb-tree, der dvbloop (angepaßt an S2API und Kernel 2.6.28 ) hinzufügt (auswählbar mit make menuconfig).
Ich habe es bis jetzt nur gegen den s2-liplianin tree getestet aber der wurde gerade erst vor ein paar Tagen gegen den Hauptzweig gesynced, so daß mein patch theoretisch auch sauber dagegen durchlaufen sollte.
Gerne mal testen und zurückmelden, ich bastel morgen (äh nachher) erstmal mein Netzteil (danke Nano, die Stecker sind angekommen!)...
ZitatOriginal von Razorblade
Gerne mal testen und zurückmelden, ich bastel morgen (äh nachher) erstmal mein Netzteil (danke Nano, die Stecker sind angekommen!)...
Prima.
Danke für den Patch. So kann man es natürlich auch machen.
Schöne Grüße
Nano
UPDATE:
Ich habe meinen Download-Link entfernt. Leider kann ich den Beitrag nicht mehr editieren. Ich werde nun auch den Patch verwenden.
Und funktioniert es? Kann es selber mangels laufendem Netceiver (noch) nicht testen...
Supi, das mit dem Versionscheck wollte ich auch einbauen wenn ich weiß ob es läuft. Ich hatte mit vi global die "class_" keywords rausgeworfen, d.h. auch im compatibility code für < 2.6.13, da muß es natürlich auch wieder rein...
Dann noch eine kurze Frage zum Netzteil, ich will mir jetzt einen Adapter von ATX auf auf den Netceiver-Stecker basteln, wie geht man am besten mit dem ATX-Power-On um? Kann ich das grüne Kabel (PIN16) einfach an einen normalen Schalter klemmen und auf der anderen Seite Masse? Wenn ja einen Kippschalter oder einen Impulsschalter (wie zB Reset)?
Ok, Netzteiladapter geht, Netceiver fängt an lustig zu blinken und irgendwann bekommt die Netzwerkkarte dann einen Gbit Link... soweit so gut.
Jetzt muß ich mich erstmal in ipv6, multicast und den restlichen Thread einlesen
Hi,
danke an alle der letzt Patch für den Kernel 2.6.28 läuft ohne Fehler.
Zitat... successfully initialized DVB Loopback Adapter Version 0.9.4-s2api
Grüße
cinfo
Hallo Leute,
wollte nur DANKE@Nano sagen !!!!
der dvbloop-s2api-0.2 patch funktioniert hier mit dem s2-liplianin & 2.6.28
saubere Arbeit
grüße
ZitatAlles anzeigenOriginal von cyberjunk
Hallo Leute,
wollte nur DANKE@Nano sagen !!!!
der dvbloop-s2api-0.2 patch funktioniert hier mit dem s2-liplianin & 2.6.28
saubere Arbeit
grüße
Danke auch an die Rasierklinge!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!