(This was originally going to be a PR, due to the
double-meaning of floppy type 0 (see the somewhat-related PR
#5364), but its scope has become large enough that a discussion
by more knowledgeable people than me might be good before any
changes are proposed via PRs or code commits, hence this request
for comments.)

>Synopsis:	The minor numbers for floppy drives go from 0-7
		for drive 0, 8-15 for drive 1, which leaves no
		room for a ``default'' type or for future
		expansion.  Plus, there are lots of nifty
		things that the floppy driver ought to support.

>Description:
	NB:  I believe the issues here affect all ports that
	use the ``PC'' floppy driver, which appears to be
	i386, sparc, sun3, arm32, pica, and bebox.

	NB:  I'm clueless about many things, including the
	kernel, so flames about my cluelessness should be via
	private E-mail to avoid wasting bandwidth.  :)

  Currently, the floppy driver chooses the format of a
disk via its minor number's lowest 3 bits.  However,
there are already 8 meaningful formats in fd.c, plus
several new formats that ought to be added:

- the format that was probed at boot time.  Some of the
  code already assumes this meaning for type 0, but this
  does not allow one to override the boot-up format with
  1.44M, since they are both type 0.
  
- the 2.88M format.

- a few of the >1.44M formats that will still work on
  standard disks and standard drives.  (Under NetBSD,
  I've gotten 1920K = 1966080 bytes (a la Linux's
  fdutils) onto a 1.44M disk using a 1.44M drive by
  changing fd.c some.)  There are at least 4 such
  formats that are handy:
    o 1520K:  80/2/19 of 512 each.  This is the most
      512-byte sectors that can fit on a 1.44M disk. 
      Some MS-DOS utilities can even handle this
      natively if you specify the 19 via a switch, IIRC.
    o 3040K:  Same, except for 2.88M disks/drives.
    o 1920K:  80/2/3 of 4096 each.  This is what I have
      working, but it still needs a bit of tweaking before
      it's ready for commit (currently, it can't handle a
      1:1 interleave at full speed, so reading a track takes
      multiple revolutions.  I can play with
      the gap sizes some more, and if it still won't
      work at full speed, perhaps the 8k/4k trick will work, or
      maybe it's just a tradeoff between capacity and speed.)
    o 3840K:  Same, except for 2.88M disks/drives.

- in addition, there are formats for 1.2M drives that
  can hold more than 1.2M, and formats for 720K drives
  that hold more than 720K, ad nauseum.

- a user-defined, run-time modifiable format, for
  people who want to play around with formats.  (Anyone
  besides me???  :)

  This adds up to at least 8 + 7 without adding any 1.2M
formats, so using only 4 bits would lead to contention
for that last slot!

  Also, it might be good to use a bit or two of the
minor number for a flag or other info.  For example,
disk throughput (of a large operation, such as
dd'ing a whole disk) can be increased by roughly 30% [*]
by formatting with a skew of 4 (which is not currently
supported).

[*]  I didn't actually re-format the disk, but I did a series of
seeks such that, on an 18-sector track, after writing the 36
sectors from the first cyl, I then tried to write sector _4_ of
cyl 1, then write sectors 5-17 and finally 0-3, followed by 4-17
and 0-3 from head 1.  On cyl 2, first write 8-17 and 0-7, then
8-17 and 0-7 on head 1, etc.  This took 35-36 seconds for the
whole disk, versus a dd that took 48-49 seconds.

  The only bad news is that changing the minor numbers to
use more bits for format (and less for drive, but how many
people really have 2^5 floppy drives on one machine?)
would break compatibility with earlier /dev directories
for any of the new /dev files.  One solution would be to
have two different majors for the fd:  the compatibility
one, with its 5/3 split of minor, and a new extended
floppy major, with a split of 3/5 or 2/6 or 2/5 with one
bit for some flag or other goody, that does all the nifty
special format stuff.  (Making the extended floppy support
an LKM would also be cool.)

  Another thing on my fd wish list is a modifiable slot or
two in the new fd_types table.  I believe that,
currently, one can format a floppy with, say, 81 tracks,
(most drives can safely use at least 82 tracks)
but there is no /dev/fd0* that would allow one to access the
81st track.  If we provide 16 slots and slot 15 of the new 0-15
format types was user-modifiable, then the user could
modify slot 15 to use 81 cyls, then format using
/dev/fd0custom with minor 15, and then dd using /dev/fd0custom
and get all 81 cyls being used.

  By the way, is there a way to modify the
currently-running kernel's data segment while it's
running, like via gdb?  I got tired of recompiling and
rebooting every time I modified a slot in fd_types, so I
wrote a program that allows one to modify any word in the
kernel, which helps, but still makes slot modifications
painstaking.  I don't yet have the know-how to use LKMs
for this.

  As additional motivation:

  1.  ``Linux has all of this'' (fdutils-x.x).  While
that is not reason in itself, it's a shame that we
don't also support using the full capacity of floppies,
considering their code is freely available.

  2.  A format like 1920K would give us even more
breathing room for boot floppies/rescue floppies,
either for a larger kernel (more device drivers) or
the capability to have more stuff in /usr/*bin.  I
don't know if such a floppy would be bootable by the
BIOS, but one can always format the first track in
1.44M mode, and put boot blocks on there that tell
the '765 controller to use 1920K format for the
remainder of the disk.  Some existing prior work does
this technique -- look at the 2m stuff in Linux's
fdutils for more references.

  Would a similar larger block size buy us as much
additional capacity from either ZIP disks or hard
drives?  Floppies could use 19 512b/sec sectors per
track, rather than 18, so the 1920K format really only
buys us 400K more (25%) capacity over the max 512b/sec
format (1520K) (and 33% over 1.44).  But a 125MB ZIP
disk would be pretty cool!  Not to mention an
additional 25% of a 4G hard drive, assuming its gap
parameters and sector headers leave as much room for
improvement as floppies.  Even if larger sectors only buy us
5-10%, 5-10% of 4G is a lot.  There's also no reason that
each partition couldn't have its own sector size, so
there's still room for compatibility issues (``boot
blocks and root partition are in 512-byte sectors, rest
is in 4K sectors for better density'').

  If anyone else wants to play around with the 1920K
format, send me mail and I can send you my current
version of fd.c.  There are lots of places in the fd
code that assume a sector size of 512 (and not all of
them are properly marked as FDC_BSIZE vs. DEV_BSIZE), so I can
spare you that heartache!  I've replaced FDC_BSIZE with
a function that returns 512, 1024, etc up to 65536 depending
on the minor number, so the modified fd.c can still use
1.44M disks.  I've successfully dd'd a 1920K kernel file
onto the disk, and then read it back, and the checksum
was the same as the original, so it appears to work fine
(and is not just silently failing or some such similar
problem).

  Lastly, although I am not yet volunteering to perform
this work (I have to worry about PhD qualifying exam in a
few weeks, not to mention end-of-semester worries like a
presentation and a research project report), if no one else
steps up, I will do my best to add these features as my time
permits.

  Thanks for your patience for reading this far!

  Happy hacking...

  Brian
-- 
Brian Grayson (bgrayson@ece.utexas.edu)
Graduate Student, Electrical and Computer Engineering
The University of Texas at Austin
Office:  ENS 406       (512) 471-8011
Finger bgrayson@orac.ece.utexas.edu for PGP key.