From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 2/4] fs/ext2: add ability to build ext3/4 too
Date: Tue, 19 Feb 2013 08:04:04 +0100 [thread overview]
Message-ID: <512323E4.7000901@mind.be> (raw)
In-Reply-To: <1a995bdbc65141cf4e8a540c41cb56f4a43fba5f.1361142401.git.yann.morin.1998@free.fr>
Great feature addition!
On 18/02/13 00:10, Yann E. MORIN wrote:
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> ---
> fs/ext2/Config.in | 37 ++++++++++++++++++++++++++++++-------
> fs/ext2/ext2.mk | 4 ++--
> fs/ext2/genext2fs.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++--
> 3 files changed, 78 insertions(+), 11 deletions(-)
>
> diff --git a/fs/ext2/Config.in b/fs/ext2/Config.in
> index cb4beed..00f11a2 100644
> --- a/fs/ext2/Config.in
> +++ b/fs/ext2/Config.in
> @@ -1,10 +1,33 @@
> config BR2_TARGET_ROOTFS_EXT2
> - bool "ext2 root filesystem"
> + bool "ext2/3/4 root filesystem"
> help
> - Build an ext2 root filesystem
> + Build an ext2/3/4 root filesystem
>
> if BR2_TARGET_ROOTFS_EXT2
>
> +choice
> + bool "ext generation"
Given the way it appears in menuconfig, I think this will be hard to
understand for many users. Perhaps "ext generation (ext2, ext3 or ext4)".
> + default BR2_TARGET_ROOTFS_EXT2_2
Although this matches the current default, doesn't it make more sense
to "bump" to ext4?
> +
> +config BR2_TARGET_ROOTFS_EXT2_2
> + bool "ext2"
> +
> +config BR2_TARGET_ROOTFS_EXT2_3
> + bool "ext3"
> + select BR2_PACKAGE_HOST_E2FSPROGS
We don't usually select the host package. On the other hand, the
support for user-selectable host packages is pretty recent, so we don't
have a real tradition for this.
Peter?
> +
> +config BR2_TARGET_ROOTFS_EXT2_4
> + bool "ext4"
> + select BR2_PACKAGE_HOST_E2FSPROGS
> +
> +endchoice
> +
> +config BR2_TARGET_ROOTFS_EXT2_GEN
> + int
> + default 2 if BR2_TARGET_ROOTFS_EXT2_2
> + default 3 if BR2_TARGET_ROOTFS_EXT2_3
> + default 4 if BR2_TARGET_ROOTFS_EXT2_4
> +
> config BR2_TARGET_ROOTFS_EXT2_BLOCKS
> int "size in blocks (leave at 0 for auto calculation)"
> default 0
[snip]
> diff --git a/fs/ext2/ext2.mk b/fs/ext2/ext2.mk
> index 7b71592..80ad93f 100644
> --- a/fs/ext2/ext2.mk
> +++ b/fs/ext2/ext2.mk
> @@ -18,10 +18,10 @@ ifneq ($(strip $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)),0)
> EXT2_OPTS += -m $(BR2_TARGET_ROOTFS_EXT2_RESBLKS)
> endif
>
> -ROOTFS_EXT2_DEPENDENCIES = host-genext2fs
> +ROOTFS_EXT2_DEPENDENCIES = host-genext2fs $(if $(BR2_PACKAGE_HOST_E2FSPROGS),host-e2fsprogs)
Although this is correct, I think it looks confusing. I prefer a more
explicit
ifeq ($(BR2_TARGET_ROOTFS_EXT2_3)$(BR2_TARGET_ROOTFS_EXT2_4),y)
ROOTFS_EXT2_DEPENDENCIES += host-e2fsprogs
endif
>
> define ROOTFS_EXT2_CMD
> - PATH=$(TARGET_PATH) fs/ext2/genext2fs.sh -d $(TARGET_DIR) $(EXT2_OPTS) $@
> + PATH=$(TARGET_PATH) fs/ext2/genext2fs.sh -d $(TARGET_DIR) $(EXT2_OPTS) -$(BR2_TARGET_ROOTFS_EXT2_GEN) $@
Minor nit: I would prefer
EXT2_OPTS += -$(BR2_TARGET_ROOTFS_EXT2_GEN)
> endef
>
> $(eval $(call ROOTFS_TARGET,ext2))
> diff --git a/fs/ext2/genext2fs.sh b/fs/ext2/genext2fs.sh
> index 7a518ae..fcbd43c 100755
> --- a/fs/ext2/genext2fs.sh
> +++ b/fs/ext2/genext2fs.sh
> @@ -1,19 +1,22 @@
> #!/bin/sh
> # genext2fs wrapper calculating needed blocks/inodes values if not specified
> +set -e
>
> export LC_ALL=C
>
> CALC_BLOCKS=1
> CALC_INODES=1
>
> -while getopts x:d:D:b:i:N:m:g:e:zfqUPhVv f
> +while getopts x:d:D:b:i:N:m:g:e:zfqUPhVv234 f
> do
> case $f in
> + 2|3|4) GEN=$f ;;
> b) CALC_BLOCKS=0 ;;
> N) CALC_INODES=0; INODES=$OPTARG ;;
> d) TARGET_DIR=$OPTARG ;;
> esac
> done
> +eval IMG="\"\${${OPTIND}}\""
>
> # calculate needed inodes
> if [ $CALC_INODES -eq 1 ];
> @@ -30,7 +33,48 @@ then
> # we scale inodes / blocks with 10% to compensate for bitmaps size + slack
> BLOCKS=$(du -s -c -k $TARGET_DIR | grep total | sed -e "s/total//")
> BLOCKS=$(expr 500 + \( $BLOCKS + $INODES / 8 \) \* 11 / 10)
> + # we add 1081 blocks (a bit more than 1 MiB, assuming 1KiB blocks) for
> + # the journal if ext3/4
Is this based on anything? Could you add something like "This allows
filesystems up to 4GiB"?
> + if [ ${GEN} -ge 3 ]; then
> + BLOCKS=$(expr 1081 + $BLOCKS )
> + fi
> set -- $@ -b $BLOCKS
> fi
>
> -exec genext2fs $@
> +# Remove -{2,3,4} from the arguments, they are not recognised
> +# by genext2fs and we handle them manually later
Wouldn't it be a lot simpler to pass the generation through the
environment instead?
> +first=1
> +for o; do
> + case "${o}" in
> + -2|-3|-4) ;;
> + *) if [ ${first} -eq 1 ]; then
> + set --
> + first=0
> + fi
> + set -- "$@" "${o}"
> + ;;
> + esac
> +done
> +
> +# Generate the base ext2 file system
> +genext2fs "$@"
> +
> +# Upgrade to ext3 if needed
> +if [ ${GEN} -ge 3 ]; then
> + tune2fs -j -J size=1 "${IMG}" >/dev/null
Ah, this is where the 1081 blocks come from. There should be a comment
pointing to that 1081 so it's easier to find this back if it is ever
changed to a different value.
Why does it have to be >/dev/null? We don't usually do that...
In the script I used, I also added -c 0 (max mount count) and -i 0
(interval between checks). That's not for this patch of course, but I
think it's something useful to have in general.
> +fi
> +
> +# Upgrade to ext4 if needed
> +if [ ${GEN} -ge 4 ]; then
> + tune2fs -O extents,uninit_bg,dir_index "${IMG}" >/dev/null
> + ret=0
> + fsck.ext4 -pDf "${IMG}" >/dev/null || ret=$?
This fsck is needed for ext3 as well, just to set rev0 -> rev1. Of
course, patch 4/4 does that already.
You should add a comment why fsck is needed.
I would use e2fsck rather than fsck.ext4, but that's a minor thing.
> + # Exit codes 1 & 2 are OK, it means fs errors
> + # were successfully corrected
> + case ${ret} in
> + 0|1|2) ;;
> + *) exit 1;;
> + esac
> + # fsck.ext4 will force a UUID, which we do not want
> + tune2fs -U clear "${IMG}" >/dev/null
Why don't we want a UUID? We have it for other filesystems, e.g. ubifs...
Regards,
Arnout
> +fi
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2013-02-19 7:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-17 23:10 [Buildroot] [pull request 'next'] Pull request for branch yem-ext234 Yann E. MORIN
2013-02-17 23:10 ` [Buildroot] [PATCH 1/4] fs/ext2: enclose the ext2 options in if...endif Yann E. MORIN
2013-02-18 7:30 ` Arnout Vandecappelle
2013-02-17 23:10 ` [Buildroot] [PATCH 2/4] fs/ext2: add ability to build ext3/4 too Yann E. MORIN
2013-02-19 7:04 ` Arnout Vandecappelle [this message]
2013-02-19 12:03 ` Peter Korsgaard
2013-02-19 15:33 ` Arnout Vandecappelle
2013-02-19 17:33 ` Yann E. MORIN
2013-02-19 19:01 ` Yann E. MORIN
2013-02-17 23:10 ` [Buildroot] [PATCH 3/4] fs/ext2: rename to 'ext' as it can now build ext2/3/4 filesystems Yann E. MORIN
2013-02-19 7:20 ` Arnout Vandecappelle
2013-02-19 12:41 ` Peter Korsgaard
2013-02-19 18:14 ` Yann E. MORIN
2013-02-19 20:48 ` Peter Korsgaard
2013-02-21 22:37 ` Yann E. MORIN
2013-02-19 17:54 ` Yann E. MORIN
2013-02-17 23:10 ` [Buildroot] [PATCH 4/4] fs/ext: add support for ext2 rev0 and rev1 Yann E. MORIN
2013-02-19 7:55 ` Arnout Vandecappelle
2013-02-19 18:10 ` Yann E. MORIN
2013-02-19 23:40 ` Arnout Vandecappelle
2013-02-19 23:47 ` Yann E. MORIN
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=512323E4.7000901@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.