[PATCH 1/1] ubi: Introduce block devices for UBI volumes

Mon Feb 10 18:19:32 EST 2014

On Mon, Feb 10, 2014 at 11:46:00PM +0100, Thomas Petazzoni wrote:
> On 2014年2月10日 23:41:54 +0100, Piergiorgio Beruto wrote:
>> > sorry for interrupting

Please, don't apoplogize. As a user of this you have all the right
-maybe the obligation- to interrupt :-)
> The point about the caching feature was not really the increased code
> size, but rather the memory consumption caused by the cache itself.
> This can be solved using a runtime configurable module parameter.
>
Yes, Artem is suggestion that direction too. The write support can be
added with an already existent block device ioctl (blockdev --setrw).
As for the cache, well... we could have a module parameter. The problem
I see in that, is that the block interface is *not* a module (as I recently
pointed out). Instead, it's integrated into the UBI core.
Therefore, it would be an UBI module parameter, such as "ubi.block_cache
= yes/no". I really don't like this.
Oh, and *please* don't ask about the non-module choice. Having the block
interface as an extension of the UBI core, the userspace interface
results very intuitive.
We have a new UBI module parameter:
 $ modprobe ubi mtd=/dev/mtd5 block=/dev/ubi0_0
And a simple tool, which re-uses the already existent UBI ioctl:
 $ ubiblkvol --attach /dev/ubi0_0
 $ ubiblkvol --detach /dev/ubi0_0
The modularized approach meant a very complex userspace interface. It
seemed to require *another* control char device:
 https://lkml.org/lkml/2011/8/15/145
*** ***
On the other side, I don't really agree with all this fuzz around the
two compile options. The code is *really* dead simple, as I went to
great extents to keep it simple.
Sadly, we are not reaching any agreement. So unless anybody has a better
idea, I'd go for a solution that suits the squashfs user: no cache,
no write support.
Artem? What do you say?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com