[RFC][PATCH 0/2] xfstests on ubifs

[RFC][PATCH 0/2] xfstests on ubifs

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

Hello,

Since ubifs encryption has been merged into the 4.10 kernel, I wanted to run my
new encryption tests on ubifs to make sure it's compatible with ext4 and f2fs.
xfstests doesn't support ubifs yet but I was able to hack something together.
I'm sending my patches for anyone who may be interested.

The first patch adds ubifs support to xfstests itself.  This is a fairly small
patch that just deals with a couple quirks of ubifs, e.g. requiring a char
device rather than a block device.

The second patch updates xfstests-bld (a separate project maintained by Theodore
Ts'o) to support ubifs with kvm-xfstests and gce-xfstests.  It uses block2mtd to
emulate MTD devices using standard block devices, then layers UBI volumes on top
of these.  Of course, actually running the tests is dependent on the xfstests
patch.

Note: I'm *not* an ubifs developer, and so far I haven't done much else besides
run the encryption tests.  There seemed to be a lot of failures when I tried
running some of the other generic xfstests, and also a strange failure in the
encryption test generic/402 that I wasn't able to fix; so if I haven't obviously
screwed something up, I strongly suggest the ubifs developers look into this.

Note 2: since mkfs.ubifs doesn't support creating encryption-capable filesystems
yet (ubifs v5), to get the encryption tests to work I also had to hack
_scratch_mkfs_encrypted() to use ubirmvol/ubimkvol instead of mkfs.  I assume
that the ubifs developers are planning to update mkfs.ubifs.

Eric

[RFC][PATCH 1/2] xfstests: add experimental support for ubifs

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

This experimental patch adds ubifs support to xfstests.  Unlike most
filesystems, ubifs is not block-device based.  Instead it uses an UBI
volume, which is layered above a MTD (raw flash) device.  An UBI volume
is represented by a char device node, e.g. /dev/ubi0_0.  To run xfstests
on ubifs, the user must set TEST_DEV to point to an UBI volume formatted
as ubifs and SCRATCH_DEV to point to some other UBI volume.  Most things
seem to just work, but a few changes were needed to allow TEST_DEV and
SCRATCH_DEV to be char devices, and to handle the lack of a fsck.ubifs.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 common/config |  7 +++++--
 common/rc     | 24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/common/config b/common/config
index 6cce7ce..cf01c9e 100644
--- a/common/config
+++ b/common/config
@@ -331,6 +331,9 @@ _mount_opts()
 		# We need to specify the size at mount, use 1G by default
 		export MOUNT_OPTIONS="-o size=1G $TMPFS_MOUNT_OPTIONS"
 		;;
+	ubifs)
+		export MOUNT_OPTIONS=$UBIFS_MOUNT_OPTIONS
+		;;
 	*)
 		;;
 	esac
@@ -461,8 +464,8 @@ _check_device()
 		if [ ! -d "$dev" ]; then
 			_fatal "common/config: $name ($dev) is not a directory for overlay"
 		fi
-	elif [ ! -b "$dev" -a "$network_dev" != "0" ]; then
-		_fatal "common/config: $name ($dev) is not a block device or a network filesystem"
+	elif [ ! -b "$dev" -a ! -c "$dev" -a "$network_dev" != "0" ]; then
+		_fatal "common/config: $name ($dev) is not a device node or network filesystem"
 	fi
 }
 
diff --git a/common/rc b/common/rc
index 2639fbd..8000abb 100644
--- a/common/rc
+++ b/common/rc
@@ -1308,6 +1308,15 @@ _require_scratch_nocheck()
 		    _notrun "this test requires a valid \$SCRATCH_MNT and unique $SCRATCH_DEV"
 		fi
 		;;
+	ubifs)
+		# ubifs needs an UBI volume. This will be a char device, not a block device.
+		if [ ! -c "$SCRATCH_DEV" ]; then
+			_notrun "this test requires a valid UBI volume for \$SCRATCH_DEV"
+		fi
+		if [ ! -d "$SCRATCH_MNT" ]; then
+			_notrun "this test requires a valid \$SCRATCH_MNT"
+		fi
+		;;
 	*)
 		 if [ -z "$SCRATCH_DEV" -o "`_is_block_dev "$SCRATCH_DEV"`" = "" ]
 		 then
@@ -1393,6 +1402,15 @@ _require_test()
 		    _notrun "this test requires a valid \$TEST_DIR and unique $TEST_DEV"
 		fi
 		;;
+	ubifs)
+		# ubifs needs an UBI volume. This will be a char device, not a block device.
+		if [ ! -c "$TEST_DEV" ]; then
+			_notrun "this test requires a valid UBI volume for \$TEST_DEV"
+		fi
+		if [ ! -d "$TEST_DIR" ]; then
+			_notrun "this test requires a valid \$TEST_DIR"
+		fi
+		;;
 	*)
 		 if [ -z "$TEST_DEV" ] || [ "`_is_block_dev "$TEST_DEV"`" = "" ]
 		 then
@@ -2171,6 +2189,9 @@ _check_test_fs()
     tmpfs)
 	# no way to check consistency for tmpfs
 	;;
+    ubifs)
+	# there is no fsck program for ubifs yet
+	;;
     *)
 	_check_generic_filesystem $TEST_DEV
 	;;
@@ -2215,6 +2236,9 @@ _check_scratch_fs()
     tmpfs)
 	# no way to check consistency for tmpfs
 	;;
+    ubifs)
+	# there is no fsck program for ubifs yet
+	;;
     *)
 	_check_generic_filesystem $device
 	;;
-- 
2.8.0.rc3.226.g39d4020

[RFC][PATCH 2/2] xfstests-bld: add experimental support for ubifs

[Eric Biggers]

From: Eric Biggers <ebiggers@google.com>

This experimental patch adds ubifs support to kvm-xfstests and
gce-xfstests.  Unlike most filesystems ubifs is not block-device based.
Instead it uses an UBI volume, which is layered above an MTD (raw flash)
device.  Fortunately it's possible to use the block2mtd kernel module to
emulate an MTD device given a block device.  This patch adds an ubifs
xfstests-bld config which uses block2mtd to create MTD devices, then UBI
devices and UBI volumes, that are backed by the kvm-xfstests or
gce-xfstests block devices.

Here are the steps to run kvm-xfstests on ubifs after this patch:

1. Patch ubifs support into xfstests using my other patch
2. Optionally, also apply my encryption patches to xfstests and xfsprogs
3. Build a kernel based on the existing xfstests-bld config but also with:
	CONFIG_MTD=y
	CONFIG_MTD_BLOCK2MTD=y
	CONFIG_MTD_UBI=y
	CONFIG_UBIFS_FS=y
	CONFIG_UBIFS_FS_ENCRYPTION=y
4. Build a kvm-xfstests rootfs that includes mtd-utils
5. Run: kvm-xfstests -c ubifs -g <group> ...

I also tried using QEMU to emulate a MTD device directly, but I couldn't
get it to work; and that definitely won't work for gce-xfstests.

Known issues (other than real test failures):

- The first time ubifs tests are run, it takes a long time to format the
  emulated MTD devices.  I don't know of a way around this other than
  simply using smaller devices.

- Using the same block devices for other filesystems and for MTD
  emulation can cause problems, e.g. without rebooting the VM, it's not
  possible to run tests on another filesystem after ubifs because
  block2mtd does not support removing MTD devices.

Signed-off-by: Eric Biggers <ebiggers@google.com>
---
 .../files/root/fs/ubifs/cfg/all.list               |   1 +
 .../test-appliance/files/root/fs/ubifs/cfg/default |  11 ++
 .../test-appliance/files/root/fs/ubifs/config      | 167 +++++++++++++++++++++
 kvm-xfstests/test-appliance/files/root/runtests.sh |   4 +-
 4 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/all.list
 create mode 100644 kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/default
 create mode 100644 kvm-xfstests/test-appliance/files/root/fs/ubifs/config

diff --git a/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/all.list b/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/all.list
new file mode 100644
index 0000000..4ad96d5
--- /dev/null
+++ b/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/all.list
@@ -0,0 +1 @@
+default
diff --git a/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/default b/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/default
new file mode 100644
index 0000000..be3ba67
--- /dev/null
+++ b/kvm-xfstests/test-appliance/files/root/fs/ubifs/cfg/default
@@ -0,0 +1,11 @@
+SIZE=small
+
+# set up UBI volumes for our block devices
+export TEST_DEV=$(__blkdev_to_ubi_volume $SM_TST_DEV)
+export TEST_DIR=$SM_TST_MNT
+export SCRATCH_DEV=$(__blkdev_to_ubi_volume $SM_SCR_DEV)
+export SCRATCH_MNT=$SM_SCR_MNT
+
+export MKFS_OPTIONS=""
+export UBIFS_MOUNT_OPTIONS=""
+TESTNAME="ubifs"
diff --git a/kvm-xfstests/test-appliance/files/root/fs/ubifs/config b/kvm-xfstests/test-appliance/files/root/fs/ubifs/config
new file mode 100644
index 0000000..91d8de6
--- /dev/null
+++ b/kvm-xfstests/test-appliance/files/root/fs/ubifs/config
@@ -0,0 +1,167 @@
+#
+# Configuration file for ubifs
+#
+
+DEFAULT_MKFS_OPTIONS=""
+
+function check_filesystem()
+{
+    # there is no fsck.ubifs yet
+    :
+}
+
+# Find the MTD device which is backed by the specified block device
+function __mtd_find()
+{
+    local blkdev=$1 mtd_dir
+
+    for mtd_dir in /sys/class/mtd/*; do
+	if [[ $mtd_dir =~ ^.*/mtd[0-9]+$ ]] &&
+	   [[ $(awk '/^block2mtd:/{print $2}' $mtd_dir/name) == $blkdev ]]
+	then
+	    echo /dev/$(basename $mtd_dir)
+	    return
+	fi
+    done
+}
+
+# Find or create the MTD device which is backed by the specified block device
+function __mtd_find_or_create()
+{
+    local blkdev=$1 mtd
+
+    if [ ! -e /sys/module/block2mtd ]; then
+	echo 1>&2 "Error: CONFIG_MTD_BLOCK2MTD=y is required to emulate flash device for ubifs!"
+	return
+    fi
+
+    mtd=$(__mtd_find $blkdev)
+    if [ ! -c "$mtd" ]; then
+	# Create a new block2mtd device.  For now choose an eraseblock size of
+	# 128 KiB.  I'm not sure if that's the best value or not.
+	echo "$blkdev,131072" > /sys/module/block2mtd/parameters/block2mtd
+	mtd=$(__mtd_find $blkdev)
+    fi
+    echo $mtd
+}
+
+# Find the UBI device which has the specified mtd device attached
+function __ubi_find()
+{
+    local mtd_num="${1#/dev/mtd}" ubi_dir
+
+    for ubi_dir in /sys/class/ubi/*; do
+	if [[ $ubi_dir =~ ^.*/ubi[0-9]+$ ]] &&
+	   [[ $(<$ubi_dir/mtd_num) == $mtd_num ]]
+	then
+	    echo /dev/$(basename $ubi_dir)
+	    return
+	fi
+    done
+}
+
+# Find or create the UBI device which has the specified mtd device attached
+function __ubi_find_or_create()
+{
+    local mtd="$1" ubi
+
+    ubi=$(__ubi_find $mtd)
+    if [ ! -c "$ubi" ]; then
+	if ! ubiattach -p $mtd &> /dev/null; then
+	    # ubiattach didn't work; try formatting the MTD device first.
+	    # Note: since this requires writing to the entire device, it may be
+	    # *very* slow...
+	    echo 1>&2 "Formatting $mtd with ubiformat (this may take a while!)..."
+	    ubiformat -e 0 -y $mtd > /dev/null
+	    ubiattach -p $mtd > /dev/null
+	fi
+	ubi=$(__ubi_find $mtd)
+    fi
+    echo $ubi
+}
+
+
+#
+# Find or create the UBI volume backed by the specified block device.
+#
+# There are four types of devices in play here.  Here's an example:
+#
+#	/dev/vdb     --- Block device
+#	/dev/mtd0    --- MTD device backed by /dev/vdb using block2mtd
+#	/dev/ubi0    --- UBI device to which /dev/mtd0 is attached
+#	/dev/ubi0_0  --- UBI volume within /dev/ubi0
+#
+# In this example, this function would take in /dev/vdb as $1 and echo back
+# /dev/ubi0_0, creating it and the two intermediary devices if needed.
+#
+function __blkdev_to_ubi_volume()
+{
+    local blkdev=$1 mtd ubi ubivol
+
+    mtd=$(__mtd_find_or_create $blkdev)
+    if [ ! -c "$mtd" ]; then
+	echo 1>&2 "Error: Failed to create MTD device from $blkdev!"
+	return
+    fi
+
+    ubi=$(__ubi_find_or_create $mtd)
+    if [ ! -c "$ubi" ]; then
+	echo 1>&2 "Error: Failed create UBI device from $mtd!"
+	return
+    fi
+
+    ubivol=${ubi}_0
+    if [ ! -c "$ubivol" ]; then
+	ubimkvol $ubi -N vol -m > /dev/null
+	if [ ! -c "$ubivol" ]; then
+	    echo 1>&2 "Error: Failed to create UBI volume $ubivol from $ubi"
+	    return
+	fi
+    fi
+    echo $ubivol
+}
+
+function format_filesystem()
+{
+    local dev="$1"
+    local opts="$2"
+
+    mkfs.ubifs -y $opts "$dev"
+}
+
+function setup_mount_opts()
+{
+    if test -n "$MNTOPTS" ; then
+	if test -n "$UBIFS_MOUNT_OPTIONS" ; then
+	    UBIFS_MOUNT_OPTIONS="$UBIFS_MOUNT_OPTIONS,$MNTOPTS"
+	else
+	    UBIFS_MOUNT_OPTIONS="-o $MNTOPTS"
+	fi
+    fi
+}
+
+function get_mkfs_opts()
+{
+    echo "$MKFS_OPTIONS"
+}
+
+function show_mkfs_opts()
+{
+    echo MKFS_OPTIONS: "$MKFS_OPTIONS"
+}
+
+function show_mount_opts()
+{
+    echo UBIFS_MOUNT_OPTIONS: "$UBIFS_MOUNT_OPTIONS"
+}
+
+function test_name_alias()
+{
+    echo "$1"
+}
+
+function reset_vars()
+{
+    unset UBIFS_MOUNT_OPTIONS
+    unset MKFS_OPTIONS
+}
diff --git a/kvm-xfstests/test-appliance/files/root/runtests.sh b/kvm-xfstests/test-appliance/files/root/runtests.sh
index c40060e..342bfe6 100755
--- a/kvm-xfstests/test-appliance/files/root/runtests.sh
+++ b/kvm-xfstests/test-appliance/files/root/runtests.sh
@@ -274,11 +274,11 @@ do
 	    */ovl) ;;
 	    *:/*) ;;
 	    *)
-		if ! test -b $TEST_DEV ; then
+		if ! [ -b $TEST_DEV -o -c $TEST_DEV ]; then
 		    echo "Test device $TEST_DEV does not exist, skipping $i config"
 		    continue
 		fi
-		if ! test -b $SCRATCH_DEV ; then
+		if ! [ -b $SCRATCH_DEV -o -c $SCRATCH_DEV ]; then
 		    echo "Scratch device $SCRATCH_DEV does not exist, skipping $i config"
 		    continue
 		fi
-- 
2.8.0.rc3.226.g39d4020

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Richard Weinberger]

Eric,

On 19.12.2016 19:45, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Hello,
> 
> Since ubifs encryption has been merged into the 4.10 kernel, I wanted to run my
> new encryption tests on ubifs to make sure it's compatible with ext4 and f2fs.
> xfstests doesn't support ubifs yet but I was able to hack something together.
> I'm sending my patches for anyone who may be interested.

Thanks for doing this. This was already on my TODO but you were faster.

> The first patch adds ubifs support to xfstests itself.  This is a fairly small
> patch that just deals with a couple quirks of ubifs, e.g. requiring a char
> device rather than a block device.
> 
> The second patch updates xfstests-bld (a separate project maintained by Theodore
> Ts'o) to support ubifs with kvm-xfstests and gce-xfstests.  It uses block2mtd to
> emulate MTD devices using standard block devices, then layers UBI volumes on top
> of these.  Of course, actually running the tests is dependent on the xfstests
> patch.
> 
> Note: I'm *not* an ubifs developer, and so far I haven't done much else besides
> run the encryption tests.  There seemed to be a lot of failures when I tried
> running some of the other generic xfstests, and also a strange failure in the
> encryption test generic/402 that I wasn't able to fix; so if I haven't obviously
> screwed something up, I strongly suggest the ubifs developers look into this.

/me looks.

> Note 2: since mkfs.ubifs doesn't support creating encryption-capable filesystems
> yet (ubifs v5), to get the encryption tests to work I also had to hack
> _scratch_mkfs_encrypted() to use ubirmvol/ubimkvol instead of mkfs.  I assume
> that the ubifs developers are planning to update mkfs.ubifs.

You don't have to run mkfs.ubifs, just mount an empty UBI volume, UBIFS will auto-
crate a encryption capable fs.

Thanks,
//richard

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Eric Biggers]

On Mon, Dec 19, 2016 at 08:12:07PM +0100, Richard Weinberger wrote:
> 
> > Note 2: since mkfs.ubifs doesn't support creating encryption-capable filesystems
> > yet (ubifs v5), to get the encryption tests to work I also had to hack
> > _scratch_mkfs_encrypted() to use ubirmvol/ubimkvol instead of mkfs.  I assume
> > that the ubifs developers are planning to update mkfs.ubifs.
> 
> You don't have to run mkfs.ubifs, just mount an empty UBI volume, UBIFS will auto-
> crate a encryption capable fs.

Yeah, that's what I ended up doing.  I didn't include it in the official patch
since it was a complete hack, but here's what I did.  Of course the real
solution would be to update mkfs.ubifs and then just use _scratch_mkfs:

diff --git a/common/encrypt b/common/encrypt
index f09104d..261a1f7 100644
--- a/common/encrypt
+++ b/common/encrypt
@@ -71,6 +71,11 @@ _scratch_mkfs_encrypted()
 	ext4|f2fs)
 		_scratch_mkfs -O encrypt
 		;;
+	ubifs)
+		local ubi=${SCRATCH_DEV%_0}
+		ubirmvol $ubi -N vol
+		ubimkvol $ubi -N vol -m
+		;;
 	*)
 		_notrun "No encryption support for $FSTYP"
 		;;

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Eric Biggers]

Hi Richard,

On Mon, Dec 19, 2016 at 08:12:07PM +0100, Richard Weinberger wrote:
> Eric,
> 
> On 19.12.2016 19:45, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> > 
> > Hello,
> > 
> > Since ubifs encryption has been merged into the 4.10 kernel, I wanted to run my
> > new encryption tests on ubifs to make sure it's compatible with ext4 and f2fs.
> > xfstests doesn't support ubifs yet but I was able to hack something together.
> > I'm sending my patches for anyone who may be interested.
> 
> Thanks for doing this. This was already on my TODO but you were faster.
> 
> > The first patch adds ubifs support to xfstests itself.  This is a fairly small
> > patch that just deals with a couple quirks of ubifs, e.g. requiring a char
> > device rather than a block device.
> > 
> > The second patch updates xfstests-bld (a separate project maintained by Theodore
> > Ts'o) to support ubifs with kvm-xfstests and gce-xfstests.  It uses block2mtd to
> > emulate MTD devices using standard block devices, then layers UBI volumes on top
> > of these.  Of course, actually running the tests is dependent on the xfstests
> > patch.
> > 
> > Note: I'm *not* an ubifs developer, and so far I haven't done much else besides
> > run the encryption tests.  There seemed to be a lot of failures when I tried
> > running some of the other generic xfstests, and also a strange failure in the
> > encryption test generic/402 that I wasn't able to fix; so if I haven't obviously
> > screwed something up, I strongly suggest the ubifs developers look into this.
> 
> /me looks.
> 

Also, in case you weren't aware of this already, I should mention that with ext4
we have a way to do a full xfstests run with encryption enabled, to find bugs
that wouldn't be found in dedicated tests.  Basically you run xfstests with the
"test_dummy_encryption" mount option (or with the "ext4/encrypt" config for
xfstests-bld), and it makes ext4 encrypt all new files and directories without
userspace having to set up encryption policies.  It may be useful to look into
implementing this for ubifs and/or f2fs too.

(I'd actually like to get rid of test_dummy_encryption and just use the ioctls,
but currently it's not really possible because it would require some ugly hooks
in xfstests, and also the root directory cannot be encrypted because e2fsck
requires that lost+found exist and be unencrypted.  An "inherit-only" encryption
policy settable by a mkfs flag is also an option, but it seems like overkill
just for testing.  So I think we'll be stuck with test_dummy_encryption for a
while longer.  At least I've written kernel and xfstests-bld patches that make
it a little less ugly kernel-side...)

Eric

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Richard Weinberger]

On 19.12.2016 19:45, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Hello,
> 
> Since ubifs encryption has been merged into the 4.10 kernel, I wanted to run my
> new encryption tests on ubifs to make sure it's compatible with ext4 and f2fs.
> xfstests doesn't support ubifs yet but I was able to hack something together.
> I'm sending my patches for anyone who may be interested.
> 
> The first patch adds ubifs support to xfstests itself.  This is a fairly small
> patch that just deals with a couple quirks of ubifs, e.g. requiring a char
> device rather than a block device.
> 
> The second patch updates xfstests-bld (a separate project maintained by Theodore
> Ts'o) to support ubifs with kvm-xfstests and gce-xfstests.  It uses block2mtd to
> emulate MTD devices using standard block devices, then layers UBI volumes on top
> of these.  Of course, actually running the tests is dependent on the xfstests
> patch.
> 
> Note: I'm *not* an ubifs developer, and so far I haven't done much else besides
> run the encryption tests.  There seemed to be a lot of failures when I tried
> running some of the other generic xfstests, and also a strange failure in the
> encryption test generic/402 that I wasn't able to fix; so if I haven't obviously
> screwed something up, I strongly suggest the ubifs developers look into this.

BTW: Do you have a xfstests git tree with all your fscrypt related patches?

Thanks,
//richard

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Eric Biggers]

On Mon, Dec 19, 2016 at 08:48:52PM +0100, Richard Weinberger wrote:
> 
> BTW: Do you have a xfstests git tree with all your fscrypt related patches?
> 

No, I think you were Cc'ed on all the patches though.  My latest xfstests series
is:

	[PATCH v4 0/6] Add filesystem-level encryption tests

and it depends on the xfsprogs patch:

	[PATCH v2] xfs_io: implement 'set_encpolicy' and 'get_encpolicy' commands

Eric

Re: [RFC][PATCH 0/2] xfstests on ubifs

[Richard Weinberger]

On 19.12.2016 20:59, Eric Biggers wrote:
> On Mon, Dec 19, 2016 at 08:48:52PM +0100, Richard Weinberger wrote:
>>
>> BTW: Do you have a xfstests git tree with all your fscrypt related patches?
>>
> 
> No, I think you were Cc'ed on all the patches though.  My latest xfstests series
> is:
> 
> 	[PATCH v4 0/6] Add filesystem-level encryption tests
> 
> and it depends on the xfsprogs patch:
> 
> 	[PATCH v2] xfs_io: implement 'set_encpolicy' and 'get_encpolicy' commands

Yes, I was cc'ed but pulling from a git tree is still less work than picking
patches from my inbox. ;-)

Thanks,
//richard