MTD Partition problems

Vipin Malik mtd-linux at embeddedlinuxworks.com
Sat Aug 3 15:24:32 EDT 2002


> >
> > Sorry for the stupid question: If it's by design, why is it going to be
> > ripped out sometime soon?
>
>It might have made sense, when it was designed. It might just have
>been a relatively new developer making the usual mistakes. Whatever.
>
>Fact is that it is useless, the superuser can create a read only
>device simply by 'chmod -w /dev/mtd0', if she wishes. That is all
>those extra devices do, except for causing confusion and eating up
>minor numbers.

So if I read you correctly, you are saying that the partitioning code 
really works but in a quirky way: the presence of duplicate read only 
paired devices, which really provide no useful functionality.

However, if one ignores the duplicated devices, one can still use 
partitioning and mount a JFFS2 fs on one of the partitions while having 
something completely different on another and device access locking will be 
taken care of by the mtd driver (which is essentially what partitioning 
provides vs. just calling add_mtd() NUM_PARTITION times in your map file on 
the same flash chip).

Additionally, (say) /dev/mtdblock2 will really provide a handle to 
/dev/mtd4 the writable third partition on the partitioned flash chip, thus 
mounting the JFFS2 fs on the partition originally intended (the third 
partition).

Unfortunately, my tests indicate that this is not happening. I know that 
/dev/mtdblock2 (the intended third partition) is formatted. However JFFS2 
finds data here and refuses to mount on it. I think it is really being 
passes a handle to and accesses /dev/mtd2, which is the wrong partition.

/dev/mtdblock[4,5] do not exist, even though /dev/mtd[4,5] do and /dev/mtd4 
is the correct partition that I want!

Argh! I'll try your patches if you like.

Thanks for your answers.

Vipin




>People would get even more confused when suddenly the device nodes
>have different behaviour, which will definitely happen as soon as the
>ro-devices are gone. But I have some patches in my queue that will
>create confusion anyway. You do the math.
>
> > >David, 2.4.19 is released, but I am right in my exam period. Does end
> > >of August and/or beginning of September sound ok for the merge?
> >
> > Should I be using the main CVS code or some branch. The above was with
> > 2.4.19-rc3.
>
>Currently, there is no branch that tackles this problem. There was
>one, but David never took a look, was busy, and rescheduled to 'when
>2.4.19 is out'. Now I am busy,...
>
>Jörn
>
>--
>Public Domain  - Free as in Beer
>General Public - Free as in Speech
>BSD License    - Free as in Enterprise
>Shared Source  - Free as in "Work will make you..."
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/





More information about the linux-mtd mailing list