On Sat, Feb 17, 2007 at 10:14:54PM +0100, Arnd Bergmann wrote:
> On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
> > + * This unit is responsible for emulating MTD devices on top of UBI devices.
> > + * This sounds strange, but it is in fact quite useful to make legacy software
> > + * work on top of UBI. New software should use native UBI API instead.
> > + *
> > + * Gluebi emulated MTD devices of "MTD_UBIVOLUME" type. Their minimal I/O unit
> > + * size (mtd->writesize) is equivalent to the underlying flash minimal I/O
> > + * unit. The eraseblock size is equivalent to the logical UBI volume eraseblock
> > + * size.
>
> This approach doesn't seem to make sense at all. If the MTD device interface
> is flawed, the right approach should be to fix that instead. After all,
> there are not many users of the MTD interface, so you should be able to
> adapt them.
No, the MTD interface isn't flawed. gluebi is present to make things like
JFFS2 work on top of UBI volumes with very little adaptations. If you go
changing _every_ MTD user to now use either an MTD device or a native UBI
device, then the code for those users just gets bloated.
> In fact, I would expect that there is much more reason to merge the existing
> MTD interface with the block interface in the kernel, but you now introduce
> a third interface that is unrelated to the first two, and make another
> conversion to convert it back?
>
> Let's assume I want to use the wear levelling capabilities of UBI on top
> of an SD card, and use the ext3 file system on top of it. I get a stack of
>
> 1. MMC
> 2. block2mtd
> 3. UBI
> 4. gluebi
> 5. mtdblock
> 6. VFS
Assuming your SD card isn't doing wear-leveling itself within the device,
yes that is what you would get. Or you could do something slightly more sane
and use:
1. MMC
2. block2mtd
3. JFFS2
> when in an ideal world, it should just be
>
> 1. MMC
> 2. UBI
> 3. VFS
This could perhaps still be done. UBI has a general concept of an io_unit
so theoretically it could be adapted to work with the block layer in the
kernel.
josh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
