[PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD
Vitaly Wool
vwool at ru.mvista.com
Tue Nov 21 05:30:15 EST 2006
Josh Boyer wrote:
<snip>
>> +static struct mtd_blktrans_ops mtdblock_tr = {
>> + .name = "mtdblock",
>> + .major = 258,
>> + .part_bits = 0,
>> + .readsect = mtdblock_readsect,
>> + .writesect = mtdblock_writesect,
>> + .add_mtd = mtdblock_add_mtd,
>> + .remove_dev = mtdblock_remove_dev,
>> + .owner = THIS_MODULE,
>> +};
>>
>
> You went to the trouble of getting a new major number assigned... why
> not call it something other than mtdblock?
>
Agree.
>
>> Index: mips-kernel-2.6/drivers/mtd/Kconfig
>> ===================================================================
>> --- mips-kernel-2.6.orig/drivers/mtd/Kconfig
>> +++ mips-kernel-2.6/drivers/mtd/Kconfig
>> @@ -197,6 +197,13 @@ config MTD_BLOCK_RO
>> You do not need this option for use with the DiskOnChip devices. For
>> those, enable NFTL support (CONFIG_NFTL) instead.
>>
>> +config MTD_BLOCK_RO_BBFREE
>> + tristate "Readonly bad block free block device access to MTD devices"
>> + depends on MTD_BLOCK!=y && MTD && MTD_BLOCK_RO!=y
>> + help
>> + Same as readonly block driver, but this allow you to mount read-only file
>> + systems from an MTD device, containing bad blocks.
>> +
>>
>
> This part seems hacky to me... why can't use use mtdblock or
> mtdblock_ro when this is enabled? And what happens in the module case?
>
I guess this line is borrowed from MTD_BLOCK_RO:
config MTD_BLOCK_RO
tristate "Readonly block device access to MTD devices"
depends on MTD_BLOCK!=y && MTD && BLOCK
I think though that these limitations are redundant at least for
MTD_BLOCK_RO_BBFREE b/c there might be the cases where there're both
NAND and NOR chips in the system so MTD_BLOCK_RO and MTD_BLOCK_RO_BBFREE
might be needed to be present in the system at the same time.
Vitaly
More information about the linux-mtd
mailing list