Aktuelle Treiber für Octopus(ddbridge), CineS2(ngene/ddbridge), DuoFlex-S2, DuoFlex-CT, CineCT sowie TT S2-6400 (Teil 2)

dddvb Paket auf Version 0.9.14 aktualisiert.

CU
Oliver

Zitat von putty12

ich versuche das dddvb 0.9.14 auf einem hardened gentoo 64bit System (mit 3.13.6 Kernel) zu compilieren.

Bitte beachten:

In diesem Thread geht es ausschließlich um media_build_experimental, d.h. das als Erweiterung integrierte dddvb-Paket. Probleme mit einem stand-alone Build von dddvb sind hier off-topic.

Zitat

Bekomme jedoch immer folgende häßliche Fehlermeldung:

/usr/local/src/dvb/dddvb-0.9.14/dvb-core/dvbdev.c:233:51: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [enabled by default]
In file included from /usr/src/linux-3.13.6-hardened-r3/arch/x86/include/asm/string.h:4:0,
from include/linux/string.h:17,
from /usr/local/src/dvb/dddvb-0.9.14/dvb-core/dvbdev.c:26:
/usr/src/linux-3.13.6-hardened-r3/arch/x86/include/asm/string_64.h:32:14: note: expected ‘void *’ but argument is of type ‘const struct file_operations *’
/usr/local/src/dvb/dddvb-0.9.14/dvb-core/dvbdev.c:234:2: error: assignment of member ‘owner’ in read-only object <<-- Error

Alles anzeigen

Offenbar sind in dem "hardened gentoo 64bit" Kernel zentrale Datenstrukturen verändert. Wer solch einen Kernel verwenden möchte, muß selbst Hand anlegen und den Treiber entsprechend anpassen.

media_build_experimental erweitert media_build um weitere Treiber, es werden genau dieselben Kernel unterstützt. Dies sind die Original-Kernel von kernel.org. Distributionskernel gehen auch, sofern sie kritische Datenstrukturen nicht anfassen:

Zitat

Auf einem neueren openSUse klappt der compile jedoch schmerzfrei.
...
** Update: ohne grsecurity im Kernel bekomme ich den Compile durch **

CU
Oliver

Zitat von putty12

Hallo Oliver,
einige Zeit später nun folgender Status:

Dreh und Angelpunkt ist die Option CONFIG_PAX_KERNEXEC.

Der Beipackzettel sagt dazu:

Code

CONFIG_PAX_KERNEXEC Enforce non-executable kernel pages
This is the kernel land equivalent of PAGEEXEC and MPROTECT, that is, enabling this option will make it harder to inject and execute 'foreign' code in kernel memory itself

Diese Option gibt es in einem Standardkernel nicht, sie ist Bestandteil eines Patches.

Zitat

Aktiviere ich diese, geht der media_build_experimental build mit folgender Fehlermeldung schief, ansonsten läuft er durch.

/usr/local/src/dvb/media_build_experimental_20140426/v4l/dvbdev.c:226:2: error: assignment of member 'owner' in read-only object

Es handelt sich auch nur um diese einzige Stelle, alle anderen Module werden fehlerfrei, auch mit CONFIG_PAX_KERNEXEC=Y, compiliert.

Deshalb meine Frage: kann es sein, dass dvbdev.c eine unsaubere Stelle / eine unsaubere Definition hat, die nur bei CONFIG_PAX_KERNEXEC zum Compilefehler führt, bei der späteren Ausführung aber unproblematisch wäre ?

Mich macht es halt stutzig, dass sich der ganze Kernel und alle anderen Pakete mit CONFIG_PAX_KERNEXEC compilieren lassen, und auch alle anderen Module aus media_build_experimental, nur dvbdev.c nicht !?

Wie schätzt du das ein ?

Alles anzeigen

Eine Unsauberkeit kann ich an der Stelle nicht erkennen, läuft ja im Normalfall auch problemlos durch.

Wie gesagt:
Wenn man im Kernel Änderungen vornimmt, muß man dies auch in den Treibern machen, die von den geänderten Stellen abhängen. Falls Du unbedingt diese Option verwenden möchtest, mußt Du im Gentoo-Kernel-Quellcode von dvbdev.c nachschauen, was dort geändert wurde. Anschließend die Änderung in dvbdev.c des neuen Treibers nachziehen...

CU
Oliver

Zitat von sbontadi

Als ich dies schrieb, hatte ich übersehen, daß der fragliche mutex_lock/mutex_unlock bereits durch den Patch 100_dvbdev.c.diff komplett entfernt wird. Diese Änderung hatte ich aus dddvb-0.9.10 von Ralph übernommen.

Zitat

The original media dvbdev.c looks like:

Code

static int dvb_device_open(struct inode *inode, struct file *file){	struct dvb_device *dvbdev;	mutex_lock(&dvbdev_mutex);	down_read(&minor_rwsem);	dvbdev = dvb_minors[iminor(inode)];	if (dvbdev && dvbdev->fops) {		int err = 0;		const struct file_operations *new_fops;		new_fops = fops_get(dvbdev->fops);		if (!new_fops)			goto fail;		file->private_data = dvbdev;		replace_fops(file, new_fops);		if (file->f_op->open)			err = file->f_op->open(inode,file);		up_read(&minor_rwsem);		mutex_unlock(&dvbdev_mutex);		return err;	}fail:	up_read(&minor_rwsem);	mutex_unlock(&dvbdev_mutex);	return -ENODEV;}

Experimental after patching looks like:

Code

static int dvb_device_open(struct inode *inode, struct file *file){    	struct dvb_device *dvbdev;    	//mutex_lock(&dvbdev_mutex);    	down_read(&minor_rwsem);    	dvbdev = dvb_minors[iminor(inode)];    	if (dvbdev && dvbdev->fops) {            	int err = 0;            	const struct file_operations *new_fops;            	new_fops = fops_get(dvbdev->fops);            	if (!new_fops)                    	goto fail;            	file->private_data = dvbdev;            	replace_fops(file, new_fops);            	if (file->f_op->open)                    	err = file->f_op->open(inode,file);            	up_read(&minor_rwsem);            	//mutex_unlock(&dvbdev_mutex);            	return err;    	}fail:    	up_read(&minor_rwsem);    	//mutex_unlock(&dvbdev_mutex);    	return -ENODEV;}

[size=10]

Wie man sieht, ist der vorgeschlagene "mutex patch" völlig überflüssig, denn die von mir erwähnte mögliche Alternative [1] (vollständiges Entfernen des Locks) ist im Code enthalten. [2]

Zitat

Oben beschriebenen Patch wird für dvbloopback in Verbindung mit zB. Oscam um CAM/Smartcards zu lesen/entschlüsseln, verwendet.

Dieser fragwürdige Themenkomplex wird hier hoffentlich nicht weiter vertieft...

Zitat

Code

+ mutex_unlock(&dvbdev_mutex);
err = file->f_op->open(inode,file);
+ mutex_lock(&dvbdev_mutex);

Abgesehen von den Verbindungszweck, erkenne ich hier einen gewissen Wiederspruch (sollte kein Vorwurf sein).
Bezügl. den dvbloopback patch erwähnst Du (UFO), dass der mutex_unlock schlecht wäre. Das original dvbdev hat am Anfang der Routine ein mutex_lock, welche im experimental auskommentiert wurde.

Vgl. [2] + [1].

Ralph ist der DVB-Experte überhaupt, denn von ihm stammt ein großer Teil des DVB-Codes. Wenn er einen Lock entfernt, gehe ich davon aus, daß er weiß, was er tut.

Zitat

Commit ... experimental: Fix deadlock in cxd2843 driver

Dieser Commit repariert den cxd2843-Treiber aus dddvb-0.9.14, sonst nix:

--- linux/drivers/media/dvb-frontends/cxd2843.c.orig    2014-04-20 16:53:01.000000000 +0200
+++ linux/drivers/media/dvb-frontends/cxd2843.c 2014-04-24 00:48:18.863834255 +0200
@@ -332,7 +332,7 @@ static int read_tps(struct cxd_state *st
                return 0;


        freeze_regst(state);
-       readregst(state, 0x10, 0x2f, tps, 7);
+       readregst_unlocked(state, 0x10, 0x2f, tps, 7);
        unfreeze_regst(state);
        return 0;
 }
@@ -1819,7 +1819,7 @@ static int get_fe_c(struct cxd_state *st
        u8 qam;


        freeze_regst(state);
-       readregst(state, 0x40, 0x19, &qam, 1);
+       readregst_unlocked(state, 0x40, 0x19, &qam, 1);
        unfreeze_regst(state);
        p->modulation = qam & 0x07;
        return 0;

Die dvbdev-Änderung (100_dvbdev.c.diff) ist dagegen 5(!) Monate alt:

changeset 240:063c32928280 
experimental: dvbdev extensions from dddvb-0.9.10.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>


author	Oliver Endriss <o.endriss@gmx.de>
date	Tue Nov 05 19:05:29 2013 +0100 (5 months ago)
parents	ab56a6588d59 
children	8a7cd80ae39d
files	experimental/patch.d/100_dvbdev.c.diff experimental/patch.d/100_dvbdev.h.diff

Zitat

Macht das auskommentieren im experimental nicht eher etwas kaputt, vorallem für Benutzer mit gemischte Hersteller-Tuner?
Ich habe keinen cxd2843, wäre es für mich besser, die experimental auskommentierte mutex_lock/unlock patch zu deaktivieren und dafür die original dvbdev aus media zu verwenden?

Du bringst hier irgendwie 2 Patches durcheinander, die nichts miteinander zu tun haben.

CU
Oliver

Zitat von sbontadi

Wenn man bei Mercurial eine Datei auswählt und changeset anklickt, erhält man generell den letzten changeset, nicht den letzten Changeset von der Datei.
Damit habe ich natürlich die zwei Changes als Eins angesehen.

Eindeutiger ist: hg log --stat

Oder man klickt auf "file log", dann werden die relevanten Changesets aufgelistet.

Zitat

Ich bin aus einem anderen Thread aufmerksam gemacht, dass das dddvb von hier stammt: http://download.digital-devices.de/download/linux/

Das Zusammenspiel zwischen dddvb und media-build-experimental und die Versionierung ist mir noch nicht ganz klar.

Ich habe dddvb in media_build_experimental integriert. Aktuelle Version ist 0.9.14.

Zitat

Aus deinen obigen Quote habe ich abgeleitet, dass Du media-build-experimental tagst.
dddvb wird von DD entwickelt (oder mindestens das Changemanagement betrieben),

Ja.

Zitat

Ihr verwendet gegenseitig Patches.
Mit obigen Quote, wolltest Du eher sagen, dass deine Änderungen, die von dddvb erstellte Patches (insofern relevant) beinhalten.

Vielleicht kannst Du hier noch einige klärende Worten dazu sagen, vielleicht eine Info für Beitrag 1.

Von dddvb bzw. v4l-dvb-saa716x übernehme ich, was mir sinnvoll erscheint.
Gleichzeitig sollen andere Treiber weiter funktionieren.

Falls ich einen Bugfix habe, schicke ich Ralph einen entsprechenden Patch. dddvb-0.9.14c enthält z.B. meinen cxd2843-Patch.

Zitat

Da Du die Änderung von dddvb, welche nur DD Tuner unterstütz, übernohmen hast, und media-build-experimental alle Tuner kompiliert, stellte sich die Frage bei mir, welchen Einfluss dies bei einem gemischten Hersteller Tuner einsatz hat.

Keine. Andernfalls wäre es ein Fehler.

Zitat

Der dvbloopback Patch ist in etwa gleichzustellen, wie obigen ddvb Patch. In Upstream media-build gab es letztes Jahr eine Diskussion, bezügl einer dvbloopback mutex Patch Einbindung, welche von Mauro abgelehnt wurde, mit in etwa die gleiche Begründung, welche Du bezügl. den open call gemacht hast. Aus diesem Zusammenhang stammt meine Frage.

Ob Mauro einen Patch akzeptiert oder nicht, ist für mich nicht relevant.
(Und umgekehrt ist für Mauro media_build_experimental oder dddvb nicht relevant.)

Zitat

Wie und wo kann man Ralph erreichen.

Seine Kontaktadresse steht in vielen Dateien, z.B. in ddbridge.c.

CU
Oliver