Re: [PATCH] [MTD] BLOCK_RO: Readonly Block Device Layer Over MTD

[Vitaly Wool <vwool@ru.mvista.com>]

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