Messages in this thread | | | Date | Sat, 23 Feb 2008 16:33:21 +0100 | From | Jörn Engel <> | Subject | Re: [PATCH 2.6.24] block2mtd: removing a device and typo fixes |
| |
On Wed, 20 February 2008 17:30:53 +0000, Stephane Chazelas wrote: > > > > 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.
The fact is that there is _no_ interface to manage mtd. Part of the reason is this tradition to have seperate modules every couple of lines of code. In other subsystems, CONFIG_MTD_CHAR would not exist and the code always be compiled in. Simply to get _some_ interface to handle the device that is always there.
Without going much deeper into that discussion, I consider it acceptable to depend on CONFIG_MTD_CHAR for things like device removal. If you want device removal and explicitly don't want the extra code from mtdchar.c, send a patch or go find 500 bytes to save elsewhere. ;)
With that out of the way, the question remains which interface we should have. Independently of mimicking loop, I would like to have a generic interface for all mtd, not just block2mtd. Whether it is "echo 1 > /sys/.../mtd/mtdN/remove" or an ioctl(), I don't care much about.
> 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))
Logfs can use a block device directly, which still leaves loop. Enhancing block2mtd to work with files shouldn't be too hard. If anyone want a fun project to hack on...
Jörn
-- Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. -- Rob Pike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |