Re: parse_cmdline_partitions equivalent for map_info

Jörn Engel
2002-10-27T17:30:17Z

On Wed, 23 October 2002 18:22:49 +0200, Robert Kaiser wrote:
> 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 :-)

True. All you have to do is grab a couple of partitions and create a
new device from those.
A little performance gets lost, as both concat and partitioning have
to adjust the offset and do some checks. This could be done just once,
but I doubt if the performance gain will be noticeable at all. Keep it
simple, Snoopy.

> 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.

It will. Someday. But when?!?

> > 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.

Sounds interesting enough. Worth a close look, when motivation shows
up again.

> > 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.

Correct.

> > 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 ;-)

Ok, next to working autosensing then. ;-)

> > 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.

I wouldn't know, how. With current partitioning, imagine two devices,
both with two partitions.
The first device will get minor 0 for the device and minors 1 and 2
for the partitions. The second will get 3, 4 and 5.
Once you create a third partition on the first device, the second will
have 4, 5 and 6. Can you spell trouble?

This was the main issue with my new partitioning code. That and
removing those useless mtd-ro devices, they also cause tons of
problems.

> 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.

Very true.

Jörn

--
Victory in war is not repetitious.
-- Sun Tzu