Re: parse_cmdline_partitions equivalent for map_info

Robert Kaiser
2002-10-28T09:20:59Z

Am Sonntag, 27. Oktober 2002 19:00 schrieben Sie:
> On Wed, 23 October 2002 18:22:49 +0200, Robert Kaiser wrote:
> > 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.

Basically yes. As usual, the devil is in the details, like when concatenating
devices of different type with varying erase block sizes, etc. But this seems
to work pretty well now (though I'm not sure what will happen if someone
pushes it, e.g. by concatenating NAND and NOR flash..).

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

Yep. I did make a few benchmarks before I comitted the concat stuff (they
should be somewhere in the mailing list archive). The difference was not
measurable.

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

See. That's the problem. Most of the time, people (including myself, btw :-()
can't afford to spend the additional time required to bring a new concept
into shape. All we do most of the time is work on an isolated problem (such
as "add MTD support for platform XYZ"), but there is hardly enough motivation
to do a true redesign. So we end up copy-pasting mapping drivers. Sooner or
later, I fear that this will result in a Big Mess(tm).

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

Funny, this concept in the partitioning code to not only create but also
register devices at the same time bothered me too. So I added a small
modification to it when I checked in the concat code: If you look at function
add_mtd_partitions() in mtdpart.c you see that the call to add_mtd_device()
gets bypassed if the caller has passed an mtd object structure to store the
device descriptor to. So the caller (usually a mapping driver) can do the
registration of the device if (and when) it sees fit, and it can thus control
which minor number (if any) will be assigned to a partition. This small
change has probably gone largely unnoticed since it is compatible with
existing mapping drivers. Conceptually, it would have been better to do a
bold re-write of the partitioning code, but at the time I was already boldy
writing the concat code, so I was reluctant to open yet another can of worms.

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

I'm not sure but I seem to remember that removal of the mtd-ro devices has
been discussed on this list lately. I haven't been following the discussions
though.

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