Hi David, Thanks for this really great explaination. But one more thing I would like to ask is whether doc1000, doc2000 and all are not treated as a block device by there kernel ? What my understanding is, first you have to insert module for doc1000 , doc2000 and etc... and then you can insert module for mtdblock.c if they are blockk devices or mtdchar.c if they are treated as char devices. Am I right ? Because doc1000.c code inserts the entry [mtd_info] into mtd_table and then mtdblock.c or mtdchar.c then uses this entry while calling various read, write and other operations ... Please tell me if I am wrong somewher... Thanks. Sumit Sharma IBM, Bangalore. On Thu, 23 Sep 2004 David Woodhouse wrote : >On Thu, 2004-09-23 at 10:00 +0200, matrix reloaded wrote: > > I am going through the code for device drivers of MTD [Memory Technology > > Devices] and found that code in "mtdblock.c" uses interface which is for block > > devices [like register_blkdev(), blk_init_queue() etc], but there is one mor folder > > inside it named "devices" [drivers/mtd/devices] where there are some drivers for > > doc1000, doc2000 and doc2001 etc. But here the interface used for implementing > > driver is totally that of MTD devices only [like inter_module_register(), > > inter_module_unregister() etc]. > > > > Can anyone please tell me why is it like this ? > >The MTD device driver infrastructure is for devices which appear to the >system as flash -- you can directly perform read/write/erase operations >on them. > >On top of a flash device, you can implement a 'translation layer' -- a >kind of hackish pseudo-filesystem which is used to make it pretend to be >a normal block device, while taking care of wear levelling, bad block >remapping etc. We support a handful of these, including a _really_ >simple one we call 'mtdblock' which does no wear levelling or remapping >but simply responds to a 'sector' write by reading the entire eraseblock >to which it corresponds, erasing that block, and then writing back the >whole block. Thus 'mtdblock' is quite useful just for dumping images to >the flash but you should never really be using it with a 'real' file >system on it in writable mode. > >There are many types of device which have flash _inside_ them but which >also have a microcontroller to do this kind of 'translation layer' for >you. These really appear to the system as if they were a hard drive -- >CompactFlash is like this. The MTD system is not relevant for those. > >There are saner ways of using flash than making it pretend to be a block >device. JFFS2 is a log-structured file system which works directly on >flash, rather than through an extra layer of indirection. > >JFFS2 should on the supported models of DiskOnChip, although we do >support M-Systems' 'NFTL' and 'INFTL' translation layers too. > >However M-Systems _do_ make some devices which appear just as an IDE >drive. It's _possible_ that you're correct when you say that's what you >have, although _many_ people claim it's an IDE drive "just because it >says it's C: in DOS". > >-- >dwmw2 > >
