Comment 11 for bug 746473

> 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.
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:
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().
2) Let the boards that need an extra partition in front be responsible for doing the reshuffling in 1) themselves.