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

[Ezequiel Garcia]

On Mon, Feb 10, 2014 at 11:46:00PM +0100, Thomas Petazzoni wrote:
> On Mon, 10 Feb 2014 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