Disk partitioning and set up is one of the more complex parts of any linux
installer.  It involves several other things:

	1. Identifying available media, and deciding which to use.
	2. Identifying existing partitions, and deciding what to do with
	   them (delete them, keep them unchanged, resize them).
	3. Deciding how many partitions of what sizes and layouts and types
	   to make.
	4. Creating partitions.
	5. Deciding where to mount all the partitions.
	6. Formatting and initializing file systems (and swap space).
	7. Mounting partitions in /target (and swapon swap partitions)
	8. Writing fstab.

Existing tools:

Fdisk and its cousins do steps 2 through 4, and if we want to let power
users use such things, the rest of the system will have to be able to take
the result and continue on with steps 5 through 8. In particular, step 6
needs to know what type of file systems to make. It's probably best to call
such programs before everything else, if they're called at all, and then
stage 2 just takes whatever they set up as its initial conditions.

Autopartkit does all of these steps itself. That's a valid approach, but it
doesn't scale too well if we want to be able to have:

	- Plug in modules for new and exciting file system types (reiserfs,
	  ext3, xfs, raid, etc)
	- Various ways to make the decisions that need to be made (user
	  input, automatically, or some combination).

So we probably want to split the steps up. Where to place the divisions?
Some natural divisions are:

	- Everything before step 5 is quite architecture-dependent, while
	  it and everything following is pretty much the same no matter what
	  architecture, I think.
	- Step 6 can involve a wide array of tools and techniques depending
	  on file system type, and so it would make sense to make it be in
	  its own step, and acomplished by modules.
	- Steps 1 through 3 all involve a lot of decisions, which need to
	  be made somehow, whether by prompting the user or guesswork. So
	  does step 5. The rest of the steps mostly only interact with the
	  user if something goes wrong (though step 6 might need to ask
	  various questions to tune file system parameters).
	- Steps 2 and 3 are tightly bound, and if one program does both, it
	  will probably be able to interact with the user better, since a
	  single UI can be used, the user may want to jump back and forth,
	  etc.
	- Step 5 could benefit from being bound to 2 and 3 as well. On the
	  other hand, existing tools (eg: fdisk) do not so bind it.

One way it could be split up would be:

	b. Identify media, decide how to partition it, and where to mount
	   the partitions, and make the partitions. (stages 1-5)
	c. File system setup modules. (stage 6)
	d. File system mounting on /target, and fstab generation. (stages 7-8)

With this split, c. needs to know what file systems to make of what types.
This information is not going to be in the partition table. It would have
to be passed from b. to c. somehow. Likewise, d. needs to know what
partitons mount where and what type they are, and again info needs to be
passed from b.

Here's another split:

	b. Identify media, decide how to partition it, and where to mount
	   the partitions, make the partitions, and write a fstab (stage
	   1-5, and half of 8)
	c. File system setup modules. (stage 6)
	d. File system mounting on /target. (stage 7)
	e. Copy in fstab. (rest of 8)

Here the data is passed in a well-known format: the fstab. Steps c. and d.
should be able to figure out most everything they need to know based on the
fstab, except c. will need to be told which partitions to format, and which
to leave alone.

Yet another split:

	a. Identify media.
	b. For each media, decide how to partition it, and where to mount
	   the partitions. Write a fstab.
	c. Make the partitions.
	d. File system setup modules.
	e. File system mounting on /target.
	f. Copy in fstab.

This requires that b. pass on to c. data about what partitions to make
where, and that a. tell b. what media there are. It has the advantage
that this b. is quite a bit simpler than previous b's, and we maybe only
need to implement media detection and partition creation once per
architecture, while there could be several modules each implementing b. in
a different way.

On the other hand, the actual media detection, and the actual partitioning
could just be broken out into libraries, and then b.'s could just use those
libraries, thus avoiding code duplication as well, without the need to pass
so much data around between stages.


I'm still trying to figure out exactly where the steps should be split up.
I guess the only thing I'm sure of is that the file system setup step is a
separate step from everything else, and is done by drop-in modules.