ubiblk is a read-only block layer on top of UBI. It presents UBI volumes asread-only block devices (named ubiblk_X_Y, where X is the UBI device numberand Y the Volume ID).

It is used by putting a block filesystem image on a UBI volume, creating thecorresponding ubiblk device and then mounting it.

It uses the UBI API to register to UBI notifications and to read from thevolumes. It also creates a ubiblk_ctrl device node that simply receives ioctlfrom a userspace tool for creating/removing ubiblk devices.

Some code is taken from mtd_blkdevs and gluebi. Some code for the ioctl part isalso inspired from ubi's core.

Advantages of ubiblk over gluebi+mtdblock_ro:

* Simpler architecture

* The numbering of devices is much easier with ubiblk than with gluebi+mtdblock_ro. With gluebi+mtdblock_ro, you get one additional MTD device for each UBI volume, so the number of MTD devices grows quite a lot and is a bit difficult to understand. For example, mtdblock[0-4] might be your real MTD partitions, while mtdblock[5-9] might be your UBI volumes. It also means that if a new real MTD partition is added, the number of all the MTD devices exposing UBI volumes will be incremented by one, which is a bit confusing/annoying. As well, if you add an UBI volume, the mtdblock devices that are emulated on top of volumes that come after this new one will have their ID incremented.

* ubiblk devices are created on a 'on-demand' basis, which avoids wasting resources.

TODO: * the modules keeps a table of the devices which length is the maximum number of UBI volumes. There should be a better solution (linked list or, as Christoph Hellwig suggests, a radix tree (idr)).

Questions:==========I wasn't sure what magic ioctl number to use, so I settled to use the same oneas a part of UBI: 'O', which was so far only used by UBI but on a higher rangeand leaving some room for UBI to add ioctls (for nw, it uses 'O'/0x00-0x06 andubiblk uses 'O'/0x10-0x11). Is it ok or should ubiblk use a differentnumber/range ?

- New header ubiblk-user.h, contains ioctl numbers ; patch Documentation/ioctl/ioctl-numbers.txt (use the same magic as UBI but on another range, leaving expansion margin for UBI)

- Add a ioctl handler and make it use the already-existing ubiblk_{create,remove} functions (inspired from ubi/cdev.c). - Register a miscdevice (inspired from ubi/build.c) that will only receive ioctls

- Notifications: don't receive a notifications for already-existing volumes upon registration ; don't create a ubiblk device when a new UBI volume appears

- Amend commit message and Kconfig according to these previous points

TODO:===== - Use a dynamic structure for storing the ubiblk_devs (linked list or idr ?) - After this task is done, check that using ubiblkadd can't create an already-existing ubiblk device (see warning/todo in the code)

+config MTD_UBI_UBIBLK+ tristate "Read-only block transition layer on top of UBI"+ help+ Read-only block interface on top of UBI.++ This option adds ubiblk, which creates a read-ony block device from+ UBI volumes. It makes it possible to use block filesystems on top of+ UBI (and thus, on top of MTDs while avoiding bad blocks).++ ubiblk devices are created by sending appropriate ioctl to the+ ubiblk_ctrl device node.++ The devices are named ubiblkX_Y where X is the UBI number and Y is+ the Volume ID.+ endif # MTD_UBIdiff --git a/drivers/mtd/ubi/Makefile b/drivers/mtd/ubi/Makefileindex c9302a5..354b2df 100644--- a/drivers/mtd/ubi/Makefile+++ b/drivers/mtd/ubi/Makefile@@ -5,3 +5,4 @@ ubi-y += misc.o