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/
