2008-02-20 17:30:42 +0100, Jörn Engel: > On Wed, 20 February 2008 14:43:39 +0000, Stephane Chazelas wrote: > > > > note that for "loop", you have /dev/loop0, /dev/loop1... which > > makes it a pain to handle > > > > For block2mtd, you don't need several device files in /dev, you > > only need one to pass ioctls down to create mtd devices. > > > > That may end up creating new /dev devices via mtdblock or > > mtdblock_ro for instance. > > > > So I'm not sure reusing the "loop" ioctls is a good idea. > > /me notes that you dislike both existing interfaces and would prefer a > third. How likely is it that you will still like the new interface two > years down the road? How likely is it that everyone else will agree > with you? > > In the end, a painful interface is still less painful than a choice of > several incompatible ones. I used to think different and have burned my > fingers often enough to learn the lesson. :) [...]
Hi Jörn, 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. 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. Best regards, 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/
