ly
filesystem on top of UBI along with a ubifs read-write filesystem.
So, what do you think about that possibility ? Do you see alternative
approaches or other ways to address the problem of using read-only
oriented filesystems on flash (w/o reinventing the wheel) ?
Regards,
David.
--
David Wa
From: David Wagner
Hi,
This is next iteration ; the read errors issue with FS that do large requests
has been fixed (it means that all block filesystems should now work) ; the
'resized' callback is implemented.
The reuse of code from mtd_blkdevs and gluebi is now mentionned i
should make use of a linked list.
Signed-off-by: David Wagner
---
updates from v2:
* Added copyright information
* Simplify the do_ubiblk_request loop
* Fix a crash at module exit
Advantages of ubiblk over gluebi+mtdblock_ro:
* Simpler architecture
* The numbering of devices is much easier
s with generic names. In this case you
> should neither make it global nor give it a generic name.
>
fixed.
Thank you for your feedback :)
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
.
David Wagner
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message
t but will be very soon. I can already give you a link to
the debian root filesystem (to be exported through NFS) that was used ;
however I can't guarantee yet that it will work.
http://free-electrons.com/~david/pub/RFS-benchmarks.tar.lzma (1.1GB)
David.
--
David Wagner, Free Electrons
Ker
From: David Wagner
ubiblk is a read-only block layer on top of UBI. It presents UBI volumes as
read-only block devices (named ubiblk_X_Y, where X is the UBI device number
and Y the Volume ID).
It is used by putting a block filesystem image on a UBI volume, creating the
corresponding ubiblk
ubiblk_ctrl sends an appropriate ioctl to ubiblk control node.
ubiblkadd and ubiblkdel are wrappers around ubiblk_ctrl.
The syntax is:
ubiblk{add,del} x y
where x is the UBI device number and y the volume ID.
Signed-off-by: David Wagner
---
This is a preliminary version: it has the
From: David Wagner
ubiblk is a read-only block layer on top of UBI. It presents UBI volumes as
read-only block devices (named ubiblk_X_Y, where X is the UBI device number
and Y the Volume ID).
It is used by putting a block filesystem image on a UBI volume, creating the
corresponding ubiblk
---
include/mtd/ubi-user.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/mtd/ubi-user.h b/include/mtd/ubi-user.h
index 3c41097..7c8bfe3 100644
--- a/include/mtd/ubi-user.h
+++ b/include/mtd/ubi-user.h
@@ -188,6 +188,7 @@
/* Set an UBI volume property */
#define
ubiblk_ctrl sends an appropriate ioctl to ubiblk control node.
ubiblkadd and ubiblkdel are wrapper around ubiblk_ctrl.
The syntax is:
ubiblk{add,del} x y
where x is the UBI device number and y the volume ID.
Signed-off-by: David Wagner
---
Hi
This tool is intended to add and
ioctl + add a kernel
parameter and throwing the ioctl away and go back "automatically create
a ubiblk for each UBI volume"). However, I agree that it doesn't make
sense to create a ubiblk device on top of UBI volumes containing, for
instance, a ubifs.
Best Regards,
move an macro rendered useless with the linked lists
* correct some formatting in kerneldoc comments
* introduce refcounting to avoid multiple opens or closing a UBI
volume while still in use
* make checkpatch happy about assignation inside a condition
* use DEFINE_MUTEX for devlist_lock
On 11/09/2011 12:18, Artem Bityutskiy wrote:
On Fri, 2011-09-09 at 16:41 +0200, David Wagner wrote:
1. Stick with the own cdev approach - the driver becomes very simple
in this case - we review it.
This is the way it's implemented in v4, right ?
Yes, but I though I sent you some
avoids wasting
resources.
* The performance appears to be slightly better with ubiblk than
gluebi+mtdblock_ro, according to our benchmarks (see
http://elinux.org/Flash_Filesystem_Benchmarks_2.6.39)
Signed-off-by: David Wagner
---
changes since v4:
~
* Add missing headers (they
ng to our benchmarks (see
http://elinux.org/Flash_Filesystem_Benchmarks_2.6.39)
Signed-off-by: David Wagner
Cc: Artem Bityutskiy
Cc: Arnd Bergmann
---
changelog since v5:
~~~
* Use list_for_each_entry instead of list_for_each
* Add a "volume" parameter
luebi+mtdblock_ro, according to our benchmarks (see
http://elinux.org/Flash_Filesystem_Benchmarks_2.6.39)
Signed-off-by: David Wagner
Cc: Artem Bityutskiy
Cc: Arnd Bergmann
---
changes since v6:
~
For convenience the v6/v7 diff can be seen at
htt
the refcounting and if the user tries to rmmod ubiblk
when there are still open ubiblk devices, it will get an EBUSY error.
Regards,
David.
--
David Wagner, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-e
luebi+mtdblock_ro, according to our benchmarks (see
http://elinux.org/Flash_Filesystem_Benchmarks_2.6.39)
Signed-off-by: David Wagner
Cc: Artem Bityutskiy
Cc: Arnd Bergmann
---
changes since v7:
~
* It is now possible to pass the volume id OR the volume name in
luebi+mtdblock_ro, according to our benchmarks (see
http://elinux.org/Flash_Filesystem_Benchmarks_2.6.39)
Signed-off-by: David Wagner
Cc: Artem Bityutskiy
Cc: Arnd Bergmann
---
changes since v8:
~
* Update the module parameter description
Documentation/ioctl/ioctl-n
20 matches
Mail list logo
