Re: parse_cmdline_partitions equivalent for map_info

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

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