2008-02-20 18:22:50 +0100, Jörn Engel: > On Wed, 20 February 2008 17:02:31 +0000, Stephane Chazelas wrote: > > > > sorry, I wasn't very clear. > > > > With "loop", you're doing an ioctl() to /dev/loop<x> so that > > /dev/loop<x> become a block device associated with a given file. > > > > Applying that strictly to block2mtd wouldn't make sense. > > > > At the moment, when you create a new block2mtd, the only thing > > you see is an entry in /proc/mtd. > > > > You don't access that mtd device directly (there's no > > /dev/mtd<x>). Instead, you may access it via a /dev/mtdblock<x> > > if you have "block2mtd" for instance. > > Actually, there is /dev/mtd<x>. Enable CONFIG_MTD_CHAR.
Yes, my point ;). "block2mtd" creates a "mtd" out of a block device and "mtdchar" and "mtdblock" create the "char" and "block" devices out of the "mtd". This is a different concept from "loop". With "loop", you make a block device out of a file, but you do the ioctl on the target loop block device itself. With block2mtd, you can't do that. > > Here, what you need, is an API that gets a block device (with fd > > or path) and an erase size and that returns a mtd identifier. > > Erase size is a real difference, agreed. Otherwise the loop analogy is > quite good. Occasionally people are asking for file->mtd translation as > well. [...] Actually, that's what I use block2mtd for, in combination with "loop" to mount jffs2 filesystem images (always wondered if there wasn't a simpler way, BTW (other than mtdram)) Cheers, Stephane -- 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/