[ANNOUNCE] VDR developer version 1.7.11

  • Der Vdr darf nicht davon ausgehen, daß /dev/dvb/adapterX/frontendY zu /sys/class/dvb/dvbX.frontendY gehört. Udev-Regeln dürfen da umsortieren. Der Vdr muß über die Device-Node-Nummern von /dev/dvb/adapterA/frontendB nach dem passenden /sys/clas/dvb/dvbX.frontendY/dev suchen und kann danach die PCI-Ids prüfen.


    Welchen Sinn sollte es denn machen, wenn udev-Regeln da "umsortieren"?
    Manchmal habe ich das Gefühl, es werden Dinge unnötig kompliziert gemacht, nur weil man es kompliziert machen kann...


    Klaus

  • Welchen Sinn sollte es denn machen, wenn udev-Regeln da "umsortieren"?


    Um eine definierte Reihenfolge (und Zuordnung) der Karten zu erhalten (wenn ich mal eine kaputte Karte ersetze will ich nich in 20 Konfigs die Nummern neu sortieren nur weil sich dardurch die Ladereihenfolge (und damit die automatische Numerierung) ändert). Der -D Parameter und die diseqc.conf funktionieren ja nur wenn jede Karte ihre eigene feste Nummer hat.


    Ferner ist es schön einen Aufkleber mit der Device Nummer auf dem Slotblech der Karte zu haben der mit der Anzeige in femon übereinstimmt. So braucht man bei Problemen nicht lange raten.


    cu

  • Moin!


    Welchen Sinn sollte es denn machen, wenn udev-Regeln da "umsortieren"?


    Weil man eine bestimmte Reihenfolge braucht, damit z.B. die diseqc-Konfiguration passt. Wenn Treiber gleichzeitig geladen werden, kann es manchmal sein, dass sich nach einem Bootvorgang die Nummern tauschen.


    Manchmal habe ich das Gefühl, es werden Dinge unnötig kompliziert gemacht, nur weil man es kompliziert machen kann...


    Eigentlich ist der Zugriff auf die Werte mittels libudev nicht wirklich aufwendig, ich könnte dir da einen Patch zukommen lassen.
    Aber ich weiß auch, dass du möglichst wenig Abhängigkeiten von externen Bibliotheken haben möchtest. Das akzeptiere ich.
    Zur Not könnte ich ihn auch so bauen, dass libudev dynamisch geladen und benutzt wird... :)


    Lars.

  • Moin!



    Weil man eine bestimmte Reihenfolge braucht, damit z.B. die diseqc-Konfiguration passt. Wenn Treiber gleichzeitig geladen werden, kann es manchmal sein, dass sich nach einem Bootvorgang die Nummern tauschen.


    Das verstehe ich ja. Aber warum ist zwischen /dev/dvb/adapterX/frontendY und /sys/class/dvbX/frontendY kein direkter Zusammenhang?
    Wenn udev-Regeln /dev/dvb/adapterX/frontendY umnummerieren, warum wird dann nicht /sys/class/dvbX/frontendY entsprechend mit umnummeriert?


    Klaus

  • Moin!


    Wenn udev-Regeln /dev/dvb/adapterX/frontendY umnummerieren, warum wird dann nicht /sys/class/dvbX/frontendY entsprechend mit umnummeriert?


    "Eigentlich" kann man per udev auch nicht (mehr) den Pfad zu /dev/dvb/... vorgeben (das ging früher mal mit NAME="...", jetzt geht eigentlich nur noch SYMLINK+="..."), das wurde irgendwann entfernt. Deshalb behelfen sich die, die es brauchen, damit, die vom Kernel vorgegebenen Devices per Script umzubenennen (RUN="...").
    Der Kernelname "dvbX.frontendY" wird vom Kernel vorgegeben und bleibt so.
    In /sys/class/dvb/dvbX.frontendY/dev steht die Major- und Minor-Nummer. Damit müsste man vergleichen.
    Das wird dann aber bald aufwendiger, als einfach libudev zu benutzen... (lass sich durch meine Werbung dafür nicht nerven) :)


    Lars.

  • Der Vdr darf nicht davon ausgehen, daß /dev/dvb/adapterX/frontendY zu /sys/class/dvb/dvbX.frontendY gehört. Udev-Regeln dürfen da umsortieren. Der Vdr muß über die Device-Node-Nummern von /dev/dvb/adapterA/frontendB nach dem passenden /sys/clas/dvb/dvbX.frontendY/dev suchen und kann danach die PCI-Ids prüfen. Ich habe da für mich mal cDvbSdFfDeviceProbe::Probe() umgestrickt:
    ...


    Ich habe das in cDvbDeviceProbe::GetSubsystemId() jetzt mal so eingebaut:



    Falls du in HISTORY/CONTRIBUTORS genannt werden willst, bitte eine Mail mit vollem Namen an mich schicken.


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!