cdk/configure: Neue Option --with-filesystems

[flasher]

Danke

Mir ist gerade selbst aufgefallen, dass ich
--enable-filesystems="extfs,xfs,nfs,cifs,vfat,smbfs,lufs"
ans Stelle von
--with-filesystems="extfs,xfs,nfs,cifs,vfat,smbfs,lufs"

geschrieben hatte...

Gruß

[GetAway]

Ich habe auch mal getestet. Bei vfat sollte eventuell msdos.o mit erzeugt werden.
Die macht nur 10k aus. Ansonsten gefällt es mir so.

[seife]

Hast du tatsächlich ein Medium, welches du mit msdos mounten kannst, aber mit vfat nicht?

[rhabarber1848]

Bei vfat sollte eventuell msdos.o mit erzeugt werden.

Wenn Du mir sagst, warum Du msdos.o brauchst, kann ich eine zusätzliche Option erzeugen.

[dwilx]

Wäre es nicht sinnvoll in bootstrap.mk an etwa der Stelle:

if ENABLE_FS_LUFS
cd $(KERNEL_DIR) && patch -p1 -E -i $(buildprefix)/Patches/linux-2.4.33-dbox2-lufs.diff
endif
if ENABLE_FS_CIFS
gunzip -cd $(buildprefix)/Archive/cifs-1.20c-2.4.tar.gz | TAPE=- tar -x
cd $(KERNEL_DIR) && patch -p1 -E -i ./cifs_24.patch

statt Klartextpfade Variablen zu nehmen? Wäre ja möglich, dass sich mal was dran ändert.
gibts dafür nicht sowas wie:

Code: Alles auswählen

@VERSION_cifs@

oder so?
Und allgemein, wäre es nicht sinnvoll die ganzen Kernelpatche etwas zu vereinheitlichen? Da gibts ja die unterschiedlichsten Kernel-Patch-Versionen, die eigentlich nur verwirren, meine ich.

[GetAway]

Hast du tatsächlich ein Medium, welches du mit msdos mounten kannst, aber mit vfat nicht?

nö

Bei vfat sollte eventuell msdos.o mit erzeugt werden.

Wenn Du mir sagst, warum Du msdos.o brauchst, kann ich eine zusätzliche Option erzeugen.

Ich dachte nur der Vollständigkeit halber.

So wie es ist, ist es gut.

[amiga23]

Hi rhabarber1848,
kannst Du bitte Deinen ersten Post in diesem Thread updated und --enable- in --with- ändern?
So Leute wie ich, die einen Thread meist nicht ganz lesen und sich dann beschweren ist damit geholfen

[rhabarber1848]

kannst Du bitte Deinen ersten Post in diesem Thread updated und --enable- in --with- ändern

erledigt
Außerdem habe ich dort diesen Artikel verlinkt, der einige Hinweise zur Anwendung gibt:
http://forum.tuxbox-cvs.sourceforge.net ... 56#p362956

[rhabarber1848]

Wäre es nicht sinnvoll in bootstrap.mk an etwa der Stelle:

if ENABLE_FS_LUFS
cd $(KERNEL_DIR) && patch -p1 -E -i $(buildprefix)/Patches/linux-2.4.33-dbox2-lufs.diff
endif
if ENABLE_FS_CIFS
gunzip -cd $(buildprefix)/Archive/cifs-1.20c-2.4.tar.gz | TAPE=- tar -x
cd $(KERNEL_DIR) && patch -p1 -E -i ./cifs_24.patch

statt Klartextpfade Variablen zu nehmen? Wäre ja möglich, dass sich mal was dran ändert.
gibts dafür nicht sowas wie:

Code: Alles auswählen

@VERSION_cifs@

oder so?
Und allgemein, wäre es nicht sinnvoll die ganzen Kernelpatche etwas zu vereinheitlichen? Da gibts ja die unterschiedlichsten Kernel-Patch-Versionen, die eigentlich nur verwirren, meine ich.

Ich quote mal alles, da ich zu faul bin, meine Antworten dazwischen zu schieben.
Der cifs-Patch für Kernel 2.4 wird nicht mehr weiterentwickelt, daher ist nicht
davon auszugehen, dass sich der Dateiname cifs-1.20c-2.4.tar.gz in absehbarer
Zukunft ändern wird. Der Dateiname cifs_24.patch bezieht sich auf eine Datei
innerhalb von cifs-1.20c-2.4.tar.gz, daher gilt hier das gleiche.

Wegen der anderen Kernelpatches hatte ich mal eine kurze Diskussion mit seife,
wo wir uns darauf geeinigt haben, alles so zu lassen, damit auch das Kompilieren
älterer Kernelversionen möglich bleibt.

[dwilx]

Achso, is' klar.

[seife]

Wenn man die Patches / configs ändern muss, damit sie mit einer neueren Version funktionieren, dann ist es IMHO angemessen, sie auch umzubenennen. Man weiss dann eh nicht, ob sie mit der alten Version noch funktionieren.

Jetzt nachträglich umbenennen würde ich nichts, aber das wäre ja ne Regel, der man in Zukunft so etwa folgen könnte.

Und ja (anders als ich es früher vertrat ) die alten configs und patches könnte man mal löschen, schliesslich sind sie im Attic/ im CVS noch zu bekommen.
Tatsächlich hatte ich selten Verlangen danach, eine alte Version zu kompilieren, insofern kann es nicht so wichtig sein... ;-)

[rhabarber1848]

Und ja (anders als ich es früher vertrat ) die alten configs und patches könnte man mal löschen, schliesslich sind sie im Attic/ im CVS noch zu bekommen.

Dann fangen wir mal hiermit an (Kernel 2.6 nutzt nun Squashfs 3.0):

cdk/Patches/linux-2.6.23-squashfs3.3.patch
cdk/Patches/linux-2.6.25-squashfs3.3.patch
cdk/Patches/squashfs1.3r3-patch
cdk/Patches/squashfs2.0r2-patch
cdk/Patches/squashfs2.1r2-patch
cdk/Patches/squashfs2.2r2-patch
cdk/Patches/linux-2.4.32-dbox2.config
cdk/Patches/linux-2.4.32-dbox2.config-flash
cdk/Patches/linux-2.4.32-dbox2.config-flash-ide2
cdk/Patches/linux-2.6.15-dbox2.config
cdk/Patches/linux-2.6.15-dbox2.config-flash
cdk/Patches/linux-2.6.23-dbox2.config
cdk/Patches/linux-2.6.23-dbox2.config-flash
cdk/Patches/linux-2.6.25.6-dbox2.config
cdk/Patches/linux-2.6.25.6-dbox2.config-flash
cdk/Patches/linux-2.4.32-dbox2.diff
cdk/Patches/linux-2.4.33-dbox2.diff
cdk/Patches/linux-2.4.33.3-dbox2.diff
cdk/Patches/linux-2.4.34-dbox2.diff
cdk/Patches/linux-2.4.35.3-dbox2.diff
cdk/Patches/linux-2.6.12-dbox2.diff
cdk/Patches/linux-2.6.15-dbox2.diff
cdk/Patches/linux-2.6.23-dbox2.diff
cdk/Patches/linux-2.6.25-dbox2.diff

[amiga23]

Cool, bringt über 100 Kbyte

root-neutrino.squashfs mit ursprünglichem Filesystem handling:
6520832 Byte
root-neutrino.squashfs mit --with-filesystems="nfs"
6410240 Byte
Also über 100 Kbyte gespart

Beim 2.6er Kernel reicht es leider immernoch nicht um auch links mit ins image zu packen
root-neutrino.squashfs too large (6762496 > 6684672)

Da müsste ich halt doch die Spiele rauswerfen.

[dwilx]

Kleine Frage: sind die Optionen

Code: Alles auswählen

--disable-ext3

und

Code: Alles auswählen

--enable-xfs

jetzt nicht überflüssig? Die sind doch immer noch vorhanden, oder?
EDIT: --enable-xfs sollte man evtl. umbenennen, da sich das wohl auch auf die xfsprogs bezieht: --enable-xfsprogs oder sehe ich das falsch? Wird das jetzt nicht alles mit --with-filesystems abgedeckt?

Code: Alles auswählen

AC_ARG_ENABLE(ext3,
	AS_HELP_STRING(--disable-ext3,	exclude ext2/ext3 drivers in yadds and images),
	[case "${enableval}" in
		yes) enable_ext2=yes
		     enable_ext3=yes ;;
		no)  enable_ext2=no
		     DEFAULT_FS_FSTAB="" ;;
	esac],[if test "$enable_ide" = "yes"; then
		    enable_ext2=yes
		    enable_ext3=yes
		else
		    enable_ext2=no
		    enable_ext3=no
		fi])

AC_ARG_ENABLE(xfs,
	AS_HELP_STRING(--enable-xfs,	include xfs drivers in yadds and images),
	[case "${enableval}" in
		yes) XFSPROGS=xfsprogs;
		     [[ "$DEFAULT_FS_FSTAB" = "" ] && DEFAULT_FS_FSTAB="xfs" || /bin/true ] ;;
	esac],[enable_xfs=no])
AC_SUBST(XFSPROGS)

[dietmarw]

...
Beim 2.6er Kernel reicht es leider immernoch nicht um auch links mit ins image zu packen
root-neutrino.squashfs too large (6762496 > 6684672)
...

aber das du die rootpartitionsize auch einfach ein wenig vergrößern könntest ist klar?

[rhabarber1848]

Kleine Frage: sind die Optionen

Code: Alles auswählen

--disable-ext3

und

Code: Alles auswählen

--enable-xfs

jetzt nicht überflüssig?

Nein, diese Optionen sind weiterhin gültig, können aber weggelassen werden,
wenn --with-filesystems genutzt wird. Am Anfang des Threads habe
ich einige Beispiele gepostet. Mein Ziel ist es, die alten Optionen weiterhin
gültig zu halten und die neue Option nur optional anzubieten.
Das bedeutet allerdings auch, dass --disable-ext3 --enable-xfs nicht
berücksichtigt wird, wenn --with-filesystems angegeben ist.
Die neue Option --with-filesystems hat somit Vorrang vor den alten Optionen.

Die sind doch immer noch vorhanden, oder?

Ja, ich möchte nicht, dass bei skript-gesteuertem Imagebau plötzlich
die IDE- und Dateisystemmodule fehlen.

EDIT: --enable-xfs sollte man evtl. umbenennen, da sich das wohl auch auf die xfsprogs bezieht: --enable-xfsprogs oder sehe ich das falsch?

Wenn XFS aktiviert ist, ob nun per --enable-xfs oder per --with-filesystems=...xfs...,
werden xfsprogs immer mit gebaut, da war bisher so und ich sehe aus
Kompatiblitätsgründen keine Veranlassung, das zu ändern.

Wird das jetzt nicht alles mit --with-filesystems abgedeckt?

Ja, Du kannst entweder die alte oder die neue Option nehmen, das ist egal.

Noch ein paar Beispiele (nur mit XFS, auch wenn es mit MMC keinen Sinn macht):

./configure --enable-ide --disable-ext3 --enable-xfs
Diese Codezeile hat bisher IDE/MMC/XFS + diverse Netzwerkdateisystem gebaut,
nicht mehr und nicht weniger und tut es auch weiterhin.

Alternativ dazu kannst Du auch
./configure --with-filesystems=xfs --enable-ide
im Bezug auf die HDD-Dateisysteme nutzen.

Zu beachten ist, dass bei
./configure --with-filesystems=xfs
NUR das IDE-Modul aktiviert wird. Wenn Du MMC/IDE nutzen willst, musst Du
--enable-ide extra aktivieren. Die Logik dahinter: Wenn nur --with-filesystems
angegeben ist, wird IDE aktiviert, wenn ein HDD-Dateisystem angegeben wurde.
--enable-ide aktiviert IDE/MMC/EXT2+3, wenn auch --with-filesystems angegeben
ist, bleiben IDE/MMC aktiv. Am besten spielst Du mit den Optionen ein wenig
herum, um ein Gefühl dafür zu bekommen.

Wenn Du
./configure --with-filesystems=xfs --enable-mmc
angibst, wird NUR das MMC-Modul aktiviert. Nach der Bearbeitung der Option
--with-filesystems wird geprüft, ob IDE oder MMC bereits durch --enable...
aktiviert ist. Wenn nein, wird nur IDE aktiviert. Wenn also IDE und MMC
gewünscht sind, dann muss folgende Option gesetzt werden:

./configure --with-filesystems=xfs --enable-ide

Diese Befehle bedeuten bzgl. HDD-Dateisystemen das gleiche, IDE/XFS:
./configure --with-filesystems=xfs
./configure --with-filesystems=xfs --enable-ide --disable-mmc
./configure --enable-ide --disable-mmc --disable-ext3 --enable-xfs

Ein anderes Beispiel:
./configure --enable-ide --disable-ext3 --with-filesystems=nfs,vfat --enable-xfs --disable-mmc
Hier wird nun IDE/VFAT/NFS gebaut, kein EXTFS, kein XFS.
Die Optionen "--enable-ide --disable-ext3 --enable-xfs" werden ignoriert.

Zu beachten ist auch, dass der erste HDD-Dateisystem-Eintrag in --with-filesystems
als Dateisystem der HDD-Partition in /etc/fstab eingetragen wird.

[amiga23]

aber das du die rootpartitionsize auch einfach ein wenig vergrößern könntest ist klar?

Ähhh hatte ich ganz vergessen. Nachdem ich damit negative Erfahrungen gemacht hatte wollte ich lieber nicht mehr daran rumspielen.
Es muss ja eine gerade Zahl sein und SquashFS hat da irgendeine Beschränkung, so das man es nicht zu groß machen darf, sonst kann es nur noch readonly gemounted werden.

Hab jetzt mal 0x680000 genommen.
Passt und fliegt

[Houdini]

Es muss ja eine gerade Zahl sein und SquashFS hat da irgendeine Beschränkung, so das man es nicht zu groß machen darf, sonst kann es nur noch readonly gemounted werden.

Der Vollständigkeit halber:
gerade Zahl => Partitionsende muß an einer Sektorgrenze liegen (n*128k)
SquashFS nicht zu groß machen => Jffs2 (var) muß eine Mindestanzahl an freien Sektoren haben, darf also nicht zu klein sein

[Striper]

Hast du tatsächlich ein Medium, welches du mit msdos mounten kannst, aber mit vfat nicht?

nö :wink:

Bei vfat sollte eventuell msdos.o mit erzeugt werden.

Wenn Du mir sagst, warum Du msdos.o brauchst, kann ich eine zusätzliche Option erzeugen.

Ich dachte nur der Vollständigkeit halber. :)

So wie es ist, ist es gut.

Naja wenn man schon vfat aktiviert dann baut man ja auch dosfstools mit --enable-dosfstools. Dort ist dann ja auch mkfs.vfat
und mkfs.msdos drin. Das ist also dann nix halbes und nix ganzes...

Würd auch sagen: entweder msdos in beides rein, oder gar nirgens.

[rhabarber1848]

Naja wenn man schon vfat aktiviert dann baut man ja auch dosfstools mit --enable-dosfstools. Dort ist dann ja auch mkfs.vfat und mkfs.msdos drin.

Wenn vfat ausreicht, alles zu mounten, was es auf der Dbox gibt,
dann können wir mkfs.msdos weglassen, würde ich sagen.

[seife]

Man kann ein DOS fs problemlos mit vfat.o mounten. Nur andersrum nicht.
Das msdos.o benötigt man IMVHO nicht, wenn man auch vfat hat.

mkfs hat nichts mit den Filesystemmodulen zu tun. mkfs.dosfs kann sinnvoll sein, wenn man die MMC-Karte später auf einem Palm lesen will ;-)

[rhabarber1848]

Es ist also alles in Ordnung...

[Striper]

Es geht ja nicht nur ums mounten, sondern auch darum das man evtl. seine mmc mit vfat formatieren will.

/edit

Bei ext2/ext3 wird einem ja "frei Haus" mkfs.ext3 bzw. mkfs.ext2 mitgeliefert. Bei vfat braucht man für mkfs.vfat jedoch zwingend --enable-dosfstools so weit ich das sehe. Hier wird dann jedoch auch mkfs.msdos mitgeliefert was wiederum bei --with-filesystems=vfat fehlt.

Der Konsistenz wegen sollte man dann entweder msdos.o auch bauen bei --with-filesystems=vfat oder eben mkfs.msdos aus den dosfstools rauswerfen.

[rhabarber1848]

http://www.pt-1.net/nitr8/30_06_2007-smbfs.diff

Dieser Patch scheint mir der vollständigste zu sein, ich
habe ihn ans CVS angepasst und teste ihn im Moment.

Bitte sehr (ungetestet): neutrino_smbfs.diff

Patch aktualisiert:

• Kompilierfehler in smbmount@kernel 2.6 behoben
• neues target flash-smbmount, /bin/[smbmount|smbmnt] ist automatisch Teil eines Flashimages, wenn --with-filesystems=smbfs gesetzt ist
• Neutrino-Part noch ungetestet (Zeitmangel)

smbmount auf der Konsole habe ich positiv getestet, Beispiel:

Code: Alles auswählen

smbmount //server/share -c "mount /mnt"

Kleine Anmerkung zum zweiten Teil des Patches für
cdk/make/sambaserver.mk, da habe ich doch einen Bug gefunden, oder?
Das target heißt

$(flashprefix)/root/sbin/smbd

Die Dateien werden aber nach nach

$(INSTALL) $$i $(flashprefix)/root/bin

installiert... Ich habe es bei /bin belassen, da
cdk/root/etc/init.d/rcS.m4 die Dateien dort erwartet.

Ob loadmodule in rcS.m4 am Ende nötig ist, müßte noch besprochen
werden. Neutrino selbst führt "insmod smbfs" aus, sofern nötig.
Für das Mounten auf der Konsole muss das Modul aber vorher
geladen sein, für meine Tests habe ich loadmodule deshalb eingefügt.
Wenn der Neutrino-Part funktioniert, braucht der Patch in rcS.m4
nicht ins CVS.

[rhabarber1848]

Bei vfat braucht man für mkfs.vfat jedoch zwingend --enable-dosfstools

Es macht aber einen Unterschied, ob ein Tool zwingend zur Nutzung
des Dateisystems nötig ist, wie smbmount im Fall von smbfs, oder
ob das Tool nur zur Erstellung des Dateisystems nötig ist und im
späteren Betrieb nicht mehr zwingend erforderlich ist.

Deshalb halte ich das zwingende Vorhandensein von mkfs.vfat nicht
für notwendig, sofern es optional aktivierbar ist. Übrigens sehe
ich bei einem kurzen Überfliegen des Sourcecode nicht, wie mkfs.ext2/3
"frei Haus" im Image enthalten sein soll, flash-e2fsprogs ist nicht per
default aktiviert.

Evtl. könnte man mit --with-tools= etwas machen.