I used mformat for this, and was even able to crate a DOS bootable partition
   this way.

Good suggestion, but it seems that our newfs_msdos should really have
better capability (even the man page says this).

   > Writing bootsectors for FAT filesystems requires knowledge of a bunch
   > of geometry and other parameters describing the disk (or partition).
   > I can take these from the command line or from compiled in tables.

   Why not from the partition table ?
   There isn't any on floopies, but all other removable or fixed media should
   have one.
   I don't feel like writing a config entry for each different drives I need
   to format, especially when the info is already present on the disk.

Clearly, no one feels like writing unnecessary config entries.  The
information (which includes more than geometry) needs to come from
somewhere, though.

My idea was to follow the guide of newfs(8) which takes a bunch of
command line options, one of which allows selecting all the entries
from a standard table so you don't have to remember all the details.
In this case, /etc/floppytab seems the most relevant table since what
is basically being created is a floppy image (hard disk partitions
with FAT filesystems are really just floppies, of course).  Currently,
the fields in floppytab support fdformat(1) and contain geometry
information and a few hardware interface parameters.  These are not
sufficient to support all the parameters needed for the BIOS parameter
block (which includes lots besides the geometry), but those parameters
could easily be added and would not interfere with fdformat(1).  These
would be fixed entries for the "normal" floppy formats, just as they
are now.  Formatting such floppies would be as simple as, for example,

    newfs_msdos -T 1440 /dev/rfd0a

Other potential sources of the geometry information (but not the rest)
are:

- the BSD disklabel (this may not exist on all disks needing
  formating, or is it true that the DIOCGDINFO ioctl(2) will always
  yield useful geometry information about any raw disk device? is that
  geometry the BIOS geometry? if not, how is that retrieved?)

- the MBR partition table (my documentation indicates that the
  geometry is in fact not encoded there; correct me if I'm wrong)

Presumably the best approach is:

- use an explicit geometry given on the command line (either from
  /etc/floppytab or explicit options)

- try to figure out the geometry using DIOCGDINFO ioctl(2) and an
  option specifying the relevant partition; if that geometry
  corresponds to one in /etc/floppytab take the additional parameters
  from there, otherwise use defaults appropriate for hard disks

- try to figure out the geometry brute force by identifying the total
  size of the disk and checking against possibilities in
  /etc/floppytab

- punt

Any better suggestions?  Problems with the design?

   > The bootsectors also, of course, include bootcode in addition to the
   > geometry information.  The specific bootcode that is appropriate
   > depends on the OS to be booted from the filesystem.  This information
   > can also be taken from various sources: compiled in tables or an
   > external file containing a bootblock.  However, it might make sense to

   Definitively external code.

   I think there is one, yes. At last for msdos and NT I would be quite surprised
   if there wasn't liscences issues here.

So, the best idea is to compile in a few freely distributed bootblocks
(e.g., the current NetBSD "reboot now" bootblock and FreeDOS
bootblocks) and provide capability of loading any arbitrary one from
an external file.

Is there reason to support either of these possibilities?

- replacing the geometry only on an existing bootblock

- replacing the bootcode only on an existing bootblock

What if a possible replacement bootblock does not end on a sector
boundary?  Should the sector be zero padded or not?

Finally, is there anything sacred about the current command line
options used for newfs_msdos(8)?  Must the options retain their
current functionality or can that be changed?

Cheers,
Brook