Re: parse_cmdline_partitions equivalent for map_info

Robert Kaiser
2002-10-23T15:46:28Z

Hi Jörn,

Am Mittwoch, 23. Oktober 2002 16:35 schrieb Jörn Engel:
> >
> > > - 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.
> >
> > Hmm, I would have thought that mtdconcat.c does this nicely already?
>
> I would have to actually take a look, but that should do it. (1)

The whole reason of the concat layer was that I was facing a situation like
the one you describe above: BIOS block in the middle of the physical flash
address range. I had first planned to deal with it in a mapping driver (like
all the others have done before and after me), but then a discussion with
David led to my developing the concat layer as a more generic solution.

David initially wanted it to be an extension to the partitioning code because
he thought that partitioning and concatenating are closely related concepts
(which seems only logical at first glance), but after looking a little deeper
into the issue, I preferred to make it a seperate module because:

1) It turned out that there is really not much a concat layer could
sensibly share with the partitioning code. They are indeed closely
related concepts, but only in the sense that each of them is the
opposite to the other :-)
2) I wanted it to be decoupled from the partitioning code because I knew
that your re-write of same was planned to be merged. It's a pity this
did not happen.

[BTW: The concat layer has a similar problem as cmdline.c: since it was
introduced relatively late, only few mapping drivers actually use it. And
since new mapping drivers tend to be created from existing ones in a
copy-paste manner, this doesn't improve over time...]

>
> > > 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.
> >
> > why not use what is there already (cmdline.c) ?
>
> Again, see (1)
> We have two seperate issues: Creating devices and partitioning those
> devices. This is interchangeable in most cases, but not in all.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Exactly!

> If I got you right, cmdline.c cares about partitioning a device.

cmdline.c just does the tedious work of scanning the kernel commandline
options and turning the information it finds there into a data structure
(i.e. the struct mtd_partition that so many mapping drivers have hardcoded).
This structure can subsequently be passed to the partitioning code. So it is
basically just a way of specifing a partitioning scheme dynamically through
the commandline.

It does, however, support multiple MTD devices, i.e. you can specify
individual partitioning schemes for different MTD devices in a single system.

> But I
> worked on hardware that needed to create three devices on flash and
> partition two of those. Would that still work easily?

The only thing missing here (assuming you want to use physmap.c for this) is
physmap.c supporting multiple devices. If I got you right, that is what your
mphysmap.c is about.

>
> > > - A c api for the "got a d-box, hit this options" type files.
> >
> > Not sure what you mean by "c api", but generally, MTD is already a
> > nightmare to configure for a non-guru, unless there is a specific mapping
> > driver for your hardware that you can just click. So this ability to just
> > tickbox your platform should definitely stay (or even be extended) when a
> > new concept gets introduced.
>
> I mean the infrastructure to rewrite 98% of the mapping drivers in <20
> lines.
>
> The user should browse through the configuration, see d-box or
> whatever, say yes *once* and be happy. That is the best interface next
> to autosensing, no doubt.

Fully agreed!

(Hmm, actually I would even *prefer* it to autosensing because I've seen
autosense code fail so many times ;-)

> (1)
> About a year ago, I forked David's tree and rewrote the partitioning.
> The changes were quite intrusive, but the result looked good to me.
> Since then, I wanted to merge the changes back into David's tree. It
> never happened, blame goes to both of us.
> Sad result is that I continued developing my tree, you all continued
> developing David's tree and neither has looked at the other.
> Currently, two or three independent groups use my tree, most use
> David's tree and noone cares about the situation.
> Again, blame everyone. David never looked at my code. I never put it
> into nice sizeable pieces for him. And everyone else either dumped
> David's tree or ignored mine.

This is really a pity :-(

>
> So the result is that I am pretty unaware about current cvs head.
> And by now, I don't even care anymore. David is a good developer, but
> his problems and my problems don't give a very cooperative mixture.

I wouldn't be so sure about that. It seems to me that many of the problems
you were facing at the time have been addressed in David's tree in the
meantime, albeit with different methods.

>From what I gathered up to this point, it seems that a physmap.c that
supports multiple devices might make a nice addition to David's tree. And, if
this module could then be generalized to such an extent that it could replace
-say- 90% of the mapping drivers, this would solve the creeping mapping
driver inflation that we currently observe.

However, the *big* problem I see with that, is that whoever does this would
have to analyze every single mapping driver and migrate the relevant bits
into the new concept. This is tedious, not to speak of the amount of testing
that needs to be done. I doubt any one person has access to all the vast
collection of devices for which there exist mapping drivers today.

Rob

----------------------------------------------------------------
Robert Kaiser email: rkaiser@sysgo.de
SYSGO AG
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10