Re: parse_cmdline_partitions equivalent for map_info

Jörn Engel
2002-10-23T11:37:37Z

On Wed, 23 October 2002 12:27:09 +0200, Frank Neuber wrote:
> Ahh, much more better. This is a good starting point. Thanks!

My desk is a mess, my brain is a mess, my patches should be better,
but... sorry for the inconvenience!

> I try to make this more generic (if time left :-)))

Allow me to drop some ideas. Maybe someone else picks those up, before
I do:

- All the mapping drivers in drivers/mtd/maps are just specialized
and tweaked versions of physmap.c.
- physmap.c was not generic enough. I wrote mphysmap.c for a reason.
- It should be possible to provide a small api that is generic enough
to rewrite all the mapping drivers in <20 lines of code.

That's the goal. This might be the path:

- physmap.c allows for one range only. Some drivers need multiple
ranges. Pick mphysmap.c or write something similar.
- Some drivers need to cut out a small range from the middle for the
bootloader. They then concatenate the range before and after the
bootloader into one virtual partition. Find a clean solution for
this.

When physmap.c or any variant is generic enough to do all this, it
needs two or three interfaces:
- Command line, a lot of people should need that.
- A c api for the "got a d-box, hit this options" type files.
(-) Maybe a config language interface. You should cut back on the
flexibility, though, the Config.in part of the mphysmap patch is
ugly already, concatenate won't make it any better.

That is my bold vision of how it should be right. Not that I expect it
to be done, but still...

Jörn

--
Don't worry about people stealing your ideas. If your ideas are any good,
you'll have to ram them down people's throats.
-- Howard Aiken quoted by Ken Iverson quoted by Jim Horning quoted by
Raph Levien, 1979