[Angstrom-devel] h5000 - better support in defconfigman

[Paul Sokolovsky]

Hello,

On Sat, 9 Feb 2008 11:00:40 +0100
"pHilipp Zabel" <philipp.zabel at gmail.com> wrote:

[]

> > > the changes : In [machine.flash] options
> > > #kernel.subsys.mtd.block=y
> > > MTD_BLKDEVS=y
> > > MTD_BLOCK=y
> > > _should_ mean the same, but defconfigman interprets
> > > kernel.subsys.mtd.block=y as modules and it is impossible to boot
> > > without kernel panic.
> >
> > This is related to recent change from Philipp Zabel:
> > http://defconfigman.svn.sourceforge.net/viewvc/defconfigman?view=rev&revision=428
> 
> Yes, you don't _need_ mtdblock to boot from flash at all.
> "root=/dev/mtdblock3" is wrong
> "root=mtd3" is right

Thanks, that's the hint I was looking for. I even decided to re-dig
where that stuff comes from. See fs/jffs2/super.c:209 (as of linux-hh
CVS). Grepping only for comments:

        /* The preferred way of mounting in future; especially when 
           CONFIG_BLK_DEV is implemented - we specify the underlying 
           MTD device by number or by name, so that we don't require 
           block device support to be present in the kernel. */

        /* FIXME: How to do the root fs this way? */

 /* Probably mounting without the blkdev crap */
                        /* Mount by MTD device name */
/* Mount by MTD device number name */
        /* Try the old way - the hack where we allowed users to mount 
           /dev/mtdblock$(n) but didn't actually _use_ the blkdev */


That FIXME is apparently anachronism.

So, I'm going to remove h5000-specific changes.

[]
> 
> The second issue, why kernel.subsys.mtd.block=y compiles the blockdev
> translation
> as modules is not quite clear to me. base.conf has
> "kernel.subsys.mtd.block ?= m"
> (this is distro policy), but if you force it to "y" in the machine
> file afterwards, shouldn't
> that value be overwritten (apart from the fact that you shouldn't do
> that in the first place)?

Let's concentrate on pragmatic aspect here ("shouldn't do"). Otherwise,
defconfigman does not do fully correct strong/weak constraint
propagation, I intended to fix it, but taking into account that it's
interim tool and can be made to do what's needed for intended usecases,
I dropped that from todo.

[]

-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com