Re: parse_cmdline_partitions equivalent for map_info

Jörn Engel
2002-10-23T13:04:10Z

On Wed, 23 October 2002 15:25:39 +0200, Robert Kaiser wrote:
> no offense, but ...

When you're right, you're...

> Am Dienstag, 22. Oktober 2002 19:29 schrieb Jörn Engel:
> > Actually, I am not very sure about cmdline.c at all. Is there a single
> > mapping driver that could not be replaced by physmap.c or mphysmap.c?
>
> Not sure about mphysmap.c, but last time I checked, physmap.c was unable to
> deal with configurations where:
>
> - a set_vpp method is required (see cstm_mips_ixx.c, dilnetpc.c,
> sa1100-flash.c)
> - different kinds of flash chips exist (see sc520cdp.c)
> - bank switched flash is used (see octagon-5066.c, elan-104nc.c,
> sbc_gxx.c,vmax301.c)
> - offset is not a direct index into the flash (see pci.c)

Ok, you convinced me.

> > The ones I casually looked at did nothing more than hardcoding
> > addresses and similar stuff. Basically, they condense several config
> > options into a single one, making the kernel configuration easier.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ... which isn't so bad after all ...

Absolutely not!

> Given that, I would strongly suggest to encourage the use of cmdline.c
> wherever it makes sense rather than re-inventing that particular wheel and
> implementing it in {m}physmap.c where it would only be available to a subset
> of the possible configurations. Mapping devices and partitioning them are
> independent things and thus they should stay decoupled as they are.

Ok, I should have looked at the code. What mphysmap does is creating
several devices, not partitions. Partitioning should be left out of
mapping, correct.

Thank you for the correction!

Jörn