[abgeschlossen] Entwurf: IDE Menü

[dbt]

Kannst du ignorieren. Der Patch ist ohnehin nicht mehr ganz frisch und es kommt ja demnächst eine neuere Version.

[tine1084]

Der Patch ist ohnehin nicht mehr ganz frisch und es kommt ja demnächst eine neuere Version.

Das wäre natürlich super! Würde mich sehr freuen wenn dann die neue version mal ins cvs kommen würde.

mfg tine1084

[bazi98]

@all,

für alle die es noch nicht mitbekommen haben.
dbt schrieb im Neutrino auf der IPBox-Thread http://tuxbox-forum.mine.nu/forum/viewt ... 08#p367608.

Das neue überarbeitete IDE_Menü (habe mich aber auf den Namen HDD-Setup festgelegt) ist fast testfertig. Da müsste man mal schauen wie das mit den andern Boxen geht. Welche Module/Treiber werden denn auf den anderen Boxen gebraucht? Da sind auch einige Buildoptionen notwendig. Ich habe momentan etwas Zeit, da mal etwas dran zu bleiben. Das passt aber mehr hier hin.
http://www.tuxbox-cvs.sourceforge.net/for ... 51#p366051

Freut mich sehr, ich brech mir jedesmal einen ab wenn ich aus den cvs mit den alten diff ein dbox-image mit ide-Menue bauen will.

Danke dbt, bin schon ganz wuschi.

Gruss
bazi98

[mb405]

also wenn du immer auf fertige diffs wartest. naja.
selbst ist der mann.

[bazi98]

mb405,

können wollen tu ich schon, das können können ist mein Problem.

Ich hab meine Probleme immer beim anpassen eines diffs wenn sich durch ,wie in der letzten Zeit, viel im cvs getan hat, dann verlier ich zumeist den Überblick weil ich mangels Durchblick überfordert bin.

Gruss

bazi98

[dbt]

Nur zur Info, der alte diff hat mit dem momentanen Stand fast nichts mehr gemeinsam. Der Aufbau ist ganz anders. Ich könnte ja mal einige Screenshots posten, als reine Diskussionsgrundlage was die Benutzerführung angeht. Ein Diff gibts erst wenn ich der Meinung bin, dass es zumindest für einen pre-alpha-Testsnap gut genug ist. Ich benutze bisher im Novatux auch nur die gleiche Version wie im Jtg.

[dbt]

Also hier einige Previews:
Geöffnet wird das Menü wie bisher im Service-Menü, was mir aber nach wie vor etwas unpassend erscheint. Das könnte -> muss man noch ändern.

Hier alles im normal-Zustand wenn das IF deaktiviert ist.

Wenn man seine Platte drin hat, wählt man IDE-Interface aktiv bzw. IDE-Interface mit IRQ6
Einstellungen werden mit Rot sofort übernommen:
Ob die Einstellungen übernommen wurden, wird mit einer Meldung bestätigt und gelangt zurück ins Servicemenü, von wo man das Hdd-Setup aktualisiert aufrufen kann.
Die erkannten Platten werden dann angezeigt. Bitte hier nicht täuschen lassen, weil keine Temperatur angezeigt wird. Die wird nur angezeigt, wenn die Platte auch einen Sensor hat. Meine Testplatten haben leider keine

Jeder Platteneintrag ist auch ein Menüeintrag der einem zum nächsten Untermenü führt.

Hier werden dann alle erkannten Informationen zu den jeweiligen Partitionen angezeigt. Mit Grün (bzw. Gelb Slave)
Kann man dann Partitionen hinzufügen. Im dann folgendem Untermenü werden dann zur jeweiligen Partition die notwendigen Angaben für Mountpoint, Filesystem, Swap, Größe usw. gemacht und es kann formatiert werden. Da bin ich aber grad drüber. Das klappt noch nicht ganz. auch in Punkto fstab ist das etwas verzwickt und muss da noch einiges durchspielen.

Im Großen und ganzen läuft das so wie hier dargestellt ab. Für die Diskussion zur Benutzerführung, lass ich Euch mal damit alleine und schaue mal was dann demnächst dabei in einem Testsnap zu sehen sein wird.
Es sei noch erwähnt, dass ich das Vorgängermodell mit Markerfiles nicht übernommen habe. Es gibt hier keine Markerfiles. Es gibt nur ein Init-Script, dass vom Menü erzeugt wird. Das wird an passender Stelle in der rcS aufgerufen. Deshalb sind in der rcS auch keine Aufrufe für fs- oder ide-Module notwendig. Dies wird alles vom Menü in dieses init-script gezimmert. Die Umsetzung hierfür ist wieder eine andere Geschichte.
Soweit erstmal die Preview.

[rhabarber1848]

Es gibt hier keine Markerfiles. Es gibt nur ein Init-Script, dass vom Menü erzeugt wird.

Ist es möglich, nach einem Image-Update dieses IDE-Init-Script
wieder ins Image zu kopieren, um alle Einstellungen zurückzuerhalten?

[dbt]

Im Prinzip ja, wenn die Platte die Gleiche ist, kein Problem.

Code: Alles auswählen

/var/etc/init.d/init_ide

[rhabarber1848]

http://forum.tuxbox-cvs.sourceforge.net ... 15#p367615

Ausserdem habe ich noch abhängig von--enable-hddsetup bzw. --enable-mmcsetup für die jeweiligen Menüs geplant, um diese damit zu aktivieren

Warum planst Du extra cdk/configure-Optionen für das MMC/HDD-Setup-Menü?
IMHO sollten diese Menüs immer vorhanden sein, wenn ein Image mit
--enable-ide oder --enable-mmc kompiliert ist, für mich gehören beide
Sachen untrennbar zusammen.

[Striper]

Sehe ich nicht so. Wozu mmc Treiber wenn man nur eine HDD in der Box hat. Finde die Idee der Trennung sehr gut.

[rhabarber1848]

Wozu mmc Treiber wenn man nur eine HDD in der Box hat.

Es geht mir nicht um die Kernelmodule.
Die Optionen --enable-mmc und --enable-ide existieren und bleiben erhalten.
Ich habe nur gefragt, ob es Sinn macht, dazu noch

--enable-hddsetup bzw. --enable-mmcsetup für die jeweiligen Menüs

in Neutrino einzuführen. IMHO sollte das MMC-Menü in Neutrino existieren,
wenn die Kernelmodule mit --enable-mmc aktiviert wurden. Das gleiche
gilt für die IDE-Module.

[CarstenW]

ja und nur so

[dbt]

Der Gedanke, das so zu machen kam mir deswegen, weil es auch MMC-Standalone-Lösungen gibt/geben kann, ohne HDD und die auch ohne IDE-IF laufen, also nur mit den passenden mmc-Modulen. Das wäre damit abgedeckt und ausserdem gibts ja auch Puristen, die auf eine GUI für sowas gerne verzichten und es so wie bisher haben wollen. Dann würde ein einfaches --enable-ide den bisherigen Stand beibehalten. Die beiden anderen wären dann abhängig davon, also ein --disable-ide schaltet auch alle GUI-Parts dazu aus. Die beiden enables würde auch dafür sorgen, dass die Startscripte enstprechend angepasst sind. Ausserdem hat mich riker noch drauf angeschubst.

[rhabarber1848]

Der Gedanke, das so zu machen kam mir deswegen, weil es auch MMC-Standalone-Lösungen gibt/geben kann, ohne HDD und die auch ohne IDE-IF laufen, also nur mit den passenden mmc-Modulen.

--enable-mmc ist unabhängig von --enable-ide

gibts ja auch Puristen, die auf eine GUI für sowas gerne verzichten und es so wie bisher haben wollen.

Als erstes kam mir in den Kopf: "Wer es nicht mag, muss es nicht nutzen, aber
für ein paar KByte Ersparnis bei /bin/neutrino neue cdk/configure-Optionen
zu schaffen, halte ich für übertrieben".

Die beiden enables würde auch dafür sorgen, dass die Startscripte enstprechend angepasst sind.

Das ist der Knackpunkt, denke ich, nicht die Dateigröße von /bin/neutrino.

Es ist nicht unwahrscheinlich, dass Puristen ohnehin ihre eigene rcS & Co.
haben, für Deine IDE/MMC-Initskripts müssten sie dort Anpassungen
vornehmen. Oder anders gesagt, Deine Neutrino-GUI-Lösung hätte
keine Auswirkungen auf die Puristen, da die neuen IDE/MMC-Initskripts
von deren eigener rcS ohnehin nicht angefasst werden.

Allerdings frage ich mich, inwieweit das offizielle CVS Rücksicht auf
Puristen nehmen soll, insbesondere deshalb, weil Deine Lösung eine
komfortable Einrichtung der HDD/MMC ermöglicht, die für alle User
sicher eine Erleichterung darstellen wird und den Wildwuchs in den
anderen Images reduziert.

[dbt]

--enable-mmc ist unabhängig von --enable-ide

daran hatte ich nicht mehr gdacht. Das macht es sogar noch einfacher.

Es ist nicht unwahrscheinlich, dass Puristen ohnehin ihre eigene rcS & Co.
haben, für Deine IDE/MMC-Initskripts müssten sie dort Anpassungen
vornehmen. Oder anders gesagt, Deine Neutrino-GUI-Lösung hätte
keine Auswirkungen auf die Puristen, da die neuen IDE/MMC-Initskripts
von deren eigener rcS ohnehin nicht angefasst werden.

Das ist soweit klar, mir ging es hauptsächlich darum eine CVS-Basis zu haben, die ohne Änderungen das baut was man konfiguriert hat. Es ist sicherlich nicht wünschenswert immer darauf hinweisen zu müssen, dass das Menü nicht funktioniert, wenn du es ohne zwingende Änderungen baust. Das war auch ein primärer Grund dafür, warum das Vorgängermodell nicht im CVS ist, neben dem Wust von Markerfiles. Mir liegt schon einiges daran den Aufwand für sowas, was die Init-Scripte angeht, auf ein Minimum zu drücken. Und wenn die Anzahl der Marker gegen 0 geht ist das schon mal was.

Allerdings frage ich mich, inwieweit das offizielle CVS Rücksicht auf
Puristen nehmen soll, insbesondere deshalb, weil Deine Lösung eine
komfortable Einrichtung der HDD/MMC ermöglicht, die für alle User
sicher eine Erleichterung darstellen wird und den Wildwuchs in den
anderen Images reduziert.

Da gebe ich dir im Prinzip recht.

Wie das am Ende aussehen wird, können wir ja dann noch entscheiden. Ich stelle den bisherigen Stand mal unter die Kategorie Vorschlag, mehr nicht. Die Lösung, mit der alle leben können, wird dann schon rauskommen.

[dbt]

Wollte mich jetzt nicht durch die Analen der IDE-IF@dbox2-Geschichte von Anfang bis Ende durchwurschteln, daher eine kleine Zwischenfrage: Die Swapgröße war im bisherigen Stand auf 128 MB festgenagelt, hatte das einen speziellen Grund? Soll das so bleiben? Geht das überhaupt anders?
Momentan hab ich das so gemacht, dass man auf jeder Platte eine swap einrichten kann, mmc sollte auch kein Problem sein. Im Prinzip sollte nur eine einzige reichen, aber was wäre wohl am günstigsten?

[mb405]

swap wird immer eingerichtet auf festplatte. nur aktivieren kannste das jederzeit.

[dbt]

Also dann wie gehabt...

[CarstenW]

Die Swapgröße war im bisherigen Stand auf 128 MB festgenagelt, hatte das einen speziellen Grund?

Hallo,

es gab mal eine Faustregel für den SWAP.
SWAP = Doppelte Hauptspeichergröße. Trifft bei heutigen Servern/PCs nicht mehr zu (RAM ist so billig geworden), bei der dbox (würde ich sagen) gilt das noch

[dbt]

Meinte nur weil man die swaps auf mehrere hdds und mmc einrichten kann und den Platz entsprechend aufteilen könnte, aber so wie's aussieht müsste man es auch so machen können, dass man nur aktiviert und sich die Partition dafür aussucht, das kann dann auf HDD sein oder MMC, was auch immer...

[dbt]

Noch eine Zwischenfrage:
Sind diese Scripte aus dem bisherigen IDE-Menü Pflicht?:

Code: Alles auswählen

#define NEUTRINO_HDDFORMAT_START_SCRIPT CONFIGDIR "/formating.start"
#define NEUTRINO_HDDFORMAT_END_SCRIPT CONFIGDIR "/formating.end"

#define NEUTRINO_HDDCHECK_START_SCRIPT CONFIGDIR "/hddcheck.start"
#define NEUTRINO_HDDCHECK_END_SCRIPT CONFIGDIR "/hddcheck.end"

[JtG-Riker]

Noch eine Zwischenfrage:
Sind diese Scripte aus dem bisherigen IDE-Menü Pflicht?:

Code: Alles auswählen

#define NEUTRINO_HDDFORMAT_START_SCRIPT CONFIGDIR "/formating.start"
#define NEUTRINO_HDDFORMAT_END_SCRIPT CONFIGDIR "/formating.end"

#define NEUTRINO_HDDCHECK_START_SCRIPT CONFIGDIR "/hddcheck.start"
#define NEUTRINO_HDDCHECK_END_SCRIPT CONFIGDIR "/hddcheck.end"

Pflicht nicht, aber hat sich so eingebürgert, wäre schön wenn die auch da sind bzw geprüft werden


Gruß Riker

[dbt]

So wie ich das sehe, wurden die eingeführt, um samba oder nfs zu killen, falls die auf der Platte liegen sollten. Wenn das die einzigen Argumente sein sollten, kann man das auch ohne sowas lösen, oder gibts noch andere Einsatzgebiete? Die drin zu lassen wäre aber kein Problem.

[DrStoned]

Da viele Leute noch andere Anwendungen auf ihrer Festplatte gespeichert haben, würde ich das so drinlassen. So kann jeder selbst bestimmen, wie er seine Deamons, die auf der Platte laufen, beendet. Gerade zum Testen von sectionsd etc. benutze ich gerne die Festplatte. Da man die Platte nur umounten kann, wenn von Ihr keine Deamons gestartet wurden, die noch laufen, ist das für den Filesystemcheck, bzw. das Formatieren unbedingt notwendig, laufende Prozesse vor diesen Aktionen zu beenden.