Bitstreamout als vdr-user

Kontaktier doch einfach mal den Entwickler vom Bitstreamout-Plugin. Der kann dir sicher helfen.

Zitat

Original von Nelvin
So nochmal eine Zusatzinfo!

Es scheint so zu sein, daß der user vdr zwar Zugriff auf /dev/shm hat, aber leider nicht die Berechtigung die Größe der Shared Memory zu verändern. Ich habe im Changelog von bitstreamout gelesen, daß es im November eine Überarbeitung gemacht wurde, die es ermöglicht auch als user vdr Zugriff zu haben, doch leider scheint es zumindest bei mir nicht zu funktionieren!

Und wie gross ist den der shared Memory Bereich? Wenn beim Mounten
keine Option angeben wurde, ist das die Hälfte des des Speichers und
das sollte für ein paar MB eigentlich genug sein. Einfach mal in den
boot Skripten nach smhfs oder tmpfs suchen, dann sollte die mount
Zeile schnell gefunden sein. Btw: vom Speicher wird wirklich nur das benutzt
was auch allokiert wurde, d.h. der default geht in Ordnung.

Werner

Hi,

Exakt dasselbe Problem tritt bei mir auch auf (gentoo 2.6.3-r1, bitstreamout 50a). Wenn man den vdr als root startet klappt alles, als nicht-root, geht der mmap-Befehl schief. Ich habe auch ein bisschen rumprobiert und es scheint an dem Flag MAP_LOCKED zu liegen. Wenn man das weg nimmt, gehts wieder. Dass es mit "kleineren" Kernel funktioniert liegt wohl daran, dass die dieses Flag einfach ignorieren (siehe man mmap). Ich weiß nur leider nicht, wofür das Flag genau gut ist, und ob das Verhalten beabsichtigt ist.

Tschüssi

Thorsten

Zitat

Original von sithmein
Exakt dasselbe Problem tritt bei mir auch auf (gentoo 2.6.3-r1, bitstreamout 50a). Wenn man den vdr als root startet klappt alles, als nicht-root, geht der mmap-Befehl schief. Ich habe auch ein bisschen rumprobiert und es scheint an dem Flag MAP_LOCKED zu liegen. Wenn man das weg nimmt, gehts wieder. Dass es mit "kleineren" Kernel funktioniert liegt wohl daran, dass die dieses Flag einfach ignorieren (siehe man mmap). Ich weiß nur leider nicht, wofür das Flag genau gut ist, und ob das Verhalten beabsichtigt ist.

Das MAP_LOCKED wird zwar von mmap(2) ignoriert, aber ein Blick in shm_memory_tool.c,
genauer in die Funktion shm_malloc() zeigt, dass das Flag zum Aufrufen von mlock(2)
verwendet wird. Und genau hier wird abgefragt, ob root das macht oder eben nicht.
Warum unter dem gentoo Kernel eine Fehlermeldung auftritt, sei mal dahin gestellt.
Jedenfalls verhindert mlock(2) das Ausswappen der betreffenden Memory Seiten.

Werner

Hallo nochmal,

OK, jetzt hab ich's glaube ich verstanden. der mmap-Befehl ab 2.5.37 macht automatisch ein mlock, wenn man MAP_LOCKED angibt. Da das nur root darf geht das schon bei mmap schief (und nicht erst beim expliziten Aufruf von mlock), wenn man nicht root ist. Also würde ich folgenden Patch vorschlagen:

*** shm_memory_tool.c.old       Tue Mar 23 17:16:14 2004
--- shm_memory_tool.c   Tue Mar 23 17:18:36 2004
***************
*** 51,56 ****
--- 51,57 ----
        goto err;
      }


+     if (getuid() != 0) flags &= ~MAP_LOCKED; /* gives an error under kernel >= 2.5.37 otherwise */
      if ((ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, flags, shmfd, 0)) == MAP_FAILED) {
        esyslog("shm_open mmap of %s to size %d failed: %s\n",
                 name, size, strerror(errno));

Evtl. könnte man dann bei >= 2.5.37 den mlock-Aufruf gleich noch "wegoptimieren". Oder das flag MAP_LOCKED bleibt gleich ganz weg, dann gehts mit allen Kernel und mlock bleibt immer explizit drin.
War das jetzt richtig?

Tschüssi

Thorsten

So ähnlich sieht es seit ein paar Stunden auch im meiner
Arbeitsversion von bitstreamout aus

Werner

Zitat

Original von bitstreamout
So ähnlich sieht es seit ein paar Stunden auch im meiner
Arbeitsversion von bitstreamout aus

Na dann, auf sourceforge liegt nun die Version 0.50b, die sollte
von Haus aus tun.

Werner