[RFC] Definable standard directory for "tmpfs" Plugins?

Zitat von fnu

Natürlich muß dann noch geklärt werden ob die Plugins direkt in "--tmpfs" (nur ein Beispiel) direkt in das TopLevel Verzeichnis schreiben oder eben Unterverzeichnisse anlegen müssen/können.

Ich denke es wäre sinnig das genauso wie ConfigDirectory() und Co. zu handeln. Ohne Parameter landet es im Verzeichnis und mit Parameter "ConfigDirectory(PLUGIN_NAME_I18N)" legt der VDR ggf. das Unterverzeichnis an.

BTW: Ich fänds auch sinnvoll. Ich habe bei mir auch ne Menge Extragebastel um diverse Plugins (osdteletext, weatherng, burn, radio, upnp, xmltv2vdr usw.) dazu zu bringen ins tmpfs zu schreiben.
Mit einem TempDirectory() könnte da vieles automatisch laufen was jetzt noch manuelles Usergebastel benötigt.

cu

+1

Wie ist das dann? Die Verzeichnisse müssen ja immer erst angelegt werden. Bei jedem Neustart ist das tmpfs ja wieder leer.

Wenn man ConfigDirectory(PLUGIN_NAME_I18N) aufruft um den Pfad zum eigenen Konfigverzeichnis zu erfahren, dann legt der VDR das Verzeichnis an wenn es noch nicht existiert.

TempDirectory() könnte es ja analog handhaben. D.h. nach dem Aufruf von TempDirectory(<subdir>) kann das Plugin davon ausgehen das das Verzeichnis existiert und das es dort drin Schreibrechte hat.

cu

Moin!

Wenn TempDirectory eingeführt werden sollte, dann bin ich auch dafür, es wie ConfigDirectory zu handhaben und ein Unterverzeichnis pro Plugin anzulegen.
Wenn sonst zwei Plugins zufällig den gleichen Dateinamen benutzen, gäbe es Probleme.

Lars.

Zitat von mini73

Wenn TempDirectory eingeführt werden sollte, dann bin ich auch dafür, es wie ConfigDirectory zu handhaben und ein Unterverzeichnis pro Plugin anzulegen.

Streng genommen lautet die Regel bei mehr als einer Datei ein Unterverzeichnis (=PLUGIN_NAME_I18N) zu nutzen. Bei einer Datei hingegen das Hauptverzeichnis.

Wobei ich es besser fände wenn generell immer ein Unterverzeichnis genutzt wird (auch bei ConfigDirectory()). Erst mal gibts die die angesprochenen Namenskonflixte und zweitens ist es einfach übersichtlicher.

Edit: Gegen die Namenskonflike schlägt der VDR vor das der Name der Datei PLUGIN_NAME_I18N entspricht. Da halten sich die Plugins aber nicht dran.

[PLUGINS.html]

The additional plugins
directory is used to keep files from plugins apart from those of VDR itself, making sure there will be no name clashes. If a plugin  needs only one extra file, it is suggested that this file be named name.*
, where name shall be the name of the plugin.  


If a plugin needs more than one such file, it is suggested that the plugin stores these in a subdirectory of its own, named after the plugin. To easily get such a name  the functions can be given an additional string that will be appended to the returned directory name, as in  




const char *MyConfigDir = ConfigDirectory(Name());
where Name()
is the member function of the plugin class that returns the plugin's name. Again, VDR will make sure that the requested directory will exist (or return NULL
in case of an error).

cu

Zitat von Keine_Ahnung

Gegen die Namenskonflike schlägt der VDR vor das der Name der Datei PLUGIN_NAME_I18N entspricht. Da halten sich die Plugins aber nicht dran.

Wäre ja auch mal ein Wunder, wenn sich Plugin-Autoren an Vorgaben halten würden ;-).
Wenn's dann Konflikte gibt ist das deren Problem...

Klaus

Zitat von fnu

Hallo Klaus,

bezogen auf diesen Thread/Post: [xmltv2vdr] Kann nun mit "tmpfs" arbeiten ...

kam der Vorschlag auf den bereits bestehenden Standard Verzeichnissen, Config-, Resource-, Cache-, VideoDirectory ein weiteres zu definieren, für Plugins die aus verschiedenen Gründen, IMHO alle durchweg sinnvoll, ein "tmpfs" (aka ram disk) für Runtime Daten nutzen oder um die Zugriffe auf die Disk zu minimieren, nennen wir es mal TmpfsDirectory?

Plugins wie z.B. xmltv2vdr, osdteletext, ein zukünftiges epg2vdr etc. müssten dann nicht einzeln spezifisch ein Verzeichniss zugewiesen bekommen, sondern würden das aus dem VDR Service heraus übernehmen. Dort könnte dies Variable passend zum LinuxDerivat oder der VDR Distro definiert werden, FHS Standard hin oder her, es gibt wohl einige Spielarten, "/run/, "/var/run", "/tmp", /dev/shm" u.a.

Natürlich muß dann noch geklärt werden ob die Plugins direkt in "--tmpfs" (nur ein Beispiel), also direkt in das TopLevel Verzeichnis schreiben oder eben Unterverzeichnisse anlegen müssen/können.

Alles anzeigen

Zunächst mal die Frage: warum setzt man nicht einfach TMP auf den entsprechenden Pfad und benutzt das?
Immerhin wäre das doch dafür gedacht, oder?

Klaus

Wenn man das ganze wirklich "TempDirectory" nennen würde, und da wir uns nunmal auf einer Unix-Plattform bewegen, schreit das ja schon fast nach /tmp. Das haben auch viele Distributionen auf einer Ramdisk liegen.

Gegen /var/run spricht einerseits, dass dieser Bereich eigentlich für PID-Files gedacht ist (zumindest verstehe ich so den FHS) und zum anderen glaube ich mich zu erinnern, dass man dort als User garnicht schreiben kann. Zumindest war das bis vor kurzem noch so üblich, dass dort nur "root" etwas ablegen durfte. Man müsste also beim Booten dort ein Verzeichnis hinbasteln in das der User "vdr" auch schreiben kann.

Ich suche schon die ganze Zeit nach dem tieferen Sinn von /dev/shm. Richtig festlegen will sich da wohl keiner. Wenn es aber da ist, dann ist es zu 100% ein tmpfs und an vielen Stellen ist auch etwas von "für Performancesteigerung" zu lesen. Möglicherweise wäre es eine Option einfach zu prüfen ob /dev/shm da ist. Wenn ja, dann das nehmen. Wenn nein, dann auf /tmp ausweichen. Mir scheint /dev/shm auf jedem Fall sinnvoller zu sein als /var/run.

Und was die Ablage von Dateien in temporären Verzeichnissen angeht. Da gibt es auch bereits Festlegungen, bzw. Hilfsfunktionen um dies zu tun:
http://linux.die.net/man/3/mkdtemp
http://linux.die.net/man/3/mkstemp

Letztenendes ist ja Thema der Diskussion das man dem VDR sagen kann, wo dieses Verzeichnis ist. Nicht Sinn/Unsinn der verschiedenen Verzeichnisse.

Wenn man unbedingt wollte, könnte man auch noch diskutieren, ob Plugins Daten die nicht persistent sein müssen überhaupt wegschreiben müssen. So könnte osdteletext die Datein "einfach" im Speicher halten. Auf der anderen Seite ist es Realität das viele ein solches Verzeichnis verwenden und die Umsetzung bzw der Bedarf zwischen Arbeitsspeichernutzung vs. Festplattennutzung ist höchst unterschiedlich. Es gibt viele Punkte für oder gegen verschiedene Verzeichnisse. Manch einer hat /var/run auf wenige MB begrenzt, ein Verzeichnis in /dev/ zu benutzen klingt auch sehr befremdlich, in der Tat liegt dieses Verzeichnis bei Debian und Ubuntu zumindest in /run/ (/run/shm). Nach FHS ist /var/run "Run-time variable data" das sagt nichts über PID file only Nutzung. Bei genauerer Betrachtung gefiele mir im Moment /run/shm/vdr/ + Unterverzeichnisse sogar besser. Aber genug davon - das ganze ist hier doch eher OT und sollte bei Interesse anderswo diskutiert werden.

Ich wäre dafür das man der Realität Rechnung trägt und auch dem Fakt das ein Konsens bezgl des Verzeichnisses distributionübergreifend nicht vorhanden ist.

Zitat von Mreimer

Wenn man das ganze wirklich "TempDirectory" nennen würde, und da wir uns nunmal auf einer Unix-Plattform bewegen, schreit das ja schon fast nach /tmp. Das haben auch viele Distributionen auf einer Ramdisk liegen.

Das mag sein, dass das viele Distributionen tun, wenn das so ist, dann ist das eine schlecht Idee. Es gibt Programme die Dateien erheblicher Größe nach /tmp schreiben (ghostscript z.B.). Die Verhalten sich nicht unbedingt gut, wenn kein Platz mehr da ist. Für eine VDR-Distribution mag das eine gangbare Lösung sein, für eine generell purpose Distribution eher nicht.

Gerald

Zitat von steffen_b

Letztenendes ist ja Thema der Diskussion das man dem VDR sagen kann, wo dieses Verzeichnis ist. Nicht Sinn/Unsinn der verschiedenen Verzeichnisse.

Dem VDR brauchst du das garnicht sagen, da der VDR selbst davon eigentlich garnichts wissen will. Es geht wohl eher um Plugins, die aus welchem Grund auch immer ein tmpfs nutzen wollen.

Zitat

Wenn man unbedingt wollte, könnte man auch noch diskutieren, ob Plugins Daten die nicht persistent sein müssen überhaupt wegschreiben müssen. So könnte osdteletext die Datein "einfach" im Speicher halten.

Ja, das könnte man. Gerade beim osdteletext-Plugin fände ich sowas sehr praktisch.

Zitat von gda

Das mag sein, dass das viele Distributionen tun, wenn das so ist, dann ist das eine schlecht Idee.

Bei Archlinux ist /tmp eine Ramdisk und mir wäre neu, dass da jemals jemand Probleme mit gemeldet hätte. Zudem gibt es ja auch noch /var/tmp für den Fall, dass man sicherstellen will, auch auf Platte zu schreiben. Der Bereich /var/tmp muss laut FHS nämlich auch einen Reboot überleben.

Zum Thema /dev/shm:
http://git.kernel.org/cgit/lin…filesystems/tmpfs.txt#n35

Natürlich muss der VDR davon nichts wissen - aber der VDR ist ja im Prinzip der Plugin-Integrator/Dreh und Angelpunkt. Zentrale Definitionen kann man dort machen.

EDIT1:
Denkbar wäre auch das: https://github.com/lucianm/vdr…tes/blob/master/README.md - aber das ist noch sehr theoretisch oder ?

EDIT2:
Nochmal @Mreimer: Es geht nicht darum welches Veruzeichnis , es geht darum wie man es angibt.

Zitat von fnu

Mach's doch bitte nicht wieder komplizierter als es ist und dreh Kreise drum rum ...

Full Ack.

Zitat von fnu

keine Ahnung vllt. epg.data ...

Eher eine schlechte Idee. Sonst hat man nach einem Neustart keine EPG-Daten mehr, bis diese eben neugeladen wurden.

Zitat von Copperhead

Eher eine schlechte Idee. Sonst hat man nach einem Neustart keine EPG-Daten mehr, bis diese eben neugeladen wurden.

nicht unbedingt.
epg.data und channels.conf halte ich seit Längerem im ramlog-tmpfs. Dadurch wirds automatisch gesichert und auch zurück geschrieben.