Comment 12 for bug 746473

On Mon, 2011-05-09 at 18:08 +0000, Hans Odeberg wrote:
> > This feels very weird to me as the media we're writing to does not vary
> > according to the board -- it varies according to a command line switch.
> > For that reason I think it doesn't make sense to have it as a
> > BoardConfig attribute.
>
> Well, the point of putting media type as an attribute in the board
> class was that the Snowball board class needs to do slightly different
> things depending on the media type.
> Yes, having two board classes is an alternative. To me, that also
> feels very weird. Then it will be possible for a user to create an
> image using the Snowball_sdcard device, and an SD card using the
> Snowball_image device, with interesting results.

We can easily prevent that by aborting the script if incompatible
options are passed in, though. I'm not very fond of this either, but it
would be temporary anyway as we plan to drop the --mmc option.

> But, if you feel that that is what will fit best with future designs,
> then I will create two board classes. Should be simple.
>
> > I think it doesn't make sense to always leave free space at the
> > beginning of the disk for just one or two boards that might need a
> > loader partition. It is common for board configs to override the
> > standard get_sfdisk_cmd(), and that's probably what we should do
> here.
>
> Yes, that is exactly the way we're doing in the SnowballConfig:
> overloading get_sfdisk_cmd(). My point was that the standard
> get_sfdisk_cmd() for Android creates four primary partitions, which is
> the maximum number allowed in the MBR. Thus I see two options:

But you're overriding get_sfdisk_cmd() so you can create the 5
partitions you need, anyway you want, no? Maybe what you're trying to
do is extend the standard get_sfdisk_cmd() in your custom config class
by prepending to its return value the sfdisk commands to create an extra
partition at the beginning?

> 1) Change the standard get_sfdisk_cmd() to return three primary
> partitions, by moving one of the existing primary partitions into the
> extended partition. That way I can still just add a partition in front
> by overriding get_sfdisk_cmd().

I don't see a problem with that, but then you might as well move all the
partitions, with the exception of the boot one, into the extended
partition?

> 2) Let the boards that need an extra partition in front be responsible
> for doing the reshuffling in 1) themselves.