HEADS UP: floppy driver enhancements

[j...@uriah.heep.sax.de]

Well, everybody can read the commit message, it basically contains all
that is to say. I've offered the patch for review quite some time
ago, but nobody seemed to be interested (or at least nobody had some
feedback to me). So i've been running the patched system here for too
long now, it's time to get it to a wider audience.

Let me quote the BUGS and TODOs seection from the commit message
again, and comment each of it.

. All documentation update still needs to be done.

This means all manpage updates are still not done. Will do this
anytime soon, probably during the upcoming holiday season.

For the time being, for people who need to configure a device
using a non-standard density, here's a short guide on how to do
it:

There are now basically two options how to specify a floppy
density to either fdcontrol or fdformat. The simplified method
simply uses "-f fmt", where "fmt" is the number of kilobytes the
desired density should have. All the table entries that
previously used to live in the kernel driver have now been
imported to fdcontrol, so you can specify them in that simplified
form. So if you've been using 1720 KB floppies, you can create a
device entry for them (e. g. in /etc/rc.local) using:

fdcontrol -f 1722 /dev/fd0.1720

(As you can see, fdcontrol cares about the exact number of
kilobytes, since that's what can be derived from the configuration
table.)

The verbose form specifies each density detail of the mode
explicitly, using "-s fmtstr". fmtstr describes each of the
fields in struct fd_type (see <sys/fdcio.h>) except "size" (this
one is instead derived from the other values), and with "flags"
being specified as a sequence of "+flag" or "-flag" at the end of
the string. The current fmtstr can be queried using fdcontrol -F.

. Formatting not-so-standard formats yields unpredictable results; i
have yet to figure out why this happens. "Standard" formats like
720 and 1440 KB do work, however.

I currently have no idea why that happens. It seems some error
handling in fdformat is wrong, so each time an error occurs, it
starts to overwrite wrong tracks. Under normal circumstances,
this doesn't matter since you throw away bad floppies anyway...
I don't know why it's in particular impossible to format an FM
floppy, it only records garbage ID fields on the tracks. I've
debugged it down to the point where i'm convinced the
isa_dma_foo() functions are being passed the correct values for
the DMA transfers to the FDC.

. rc scripts are needed to setup device nodes with nonstandard
densities (like the old /dev/fdN.MMM we used to have).

The idea here is to provide some rc script that creates the drives
we used to have in the past. Some support has already been added
to fdcontrol to aid in this: just calling fdcontrol on a floppy
disk device returns a text string describing the drive type (1.2M
or 1.44M, basically). This can be used inside the rc script to
know which densities to configure for that particular drive.

. Obtaining device flags from the kernel environment doesn't work yet,
thus currently only drives that are present in (IA32) CMOS are
really detected. Someone who knows the odds and ends about device
flags is needed here, i can't figure out what i'm doing wrong.

This is the biggest problem so far. In particular, i'm sure the
driver won't recognize any floppy device on tha Alpha architecture
until this has been resolved. :-(

The idea is that you have something like

hint.fd.0.flags="0x4"

to specify a 1.44 MB floppy. The value itself (actually, the
lower 4 bits of the flags) specify drive types as they are usually
stored in the CMOS memory on IA32, but shifted right by 4 bits
(CMOS stores drive 0 in the upper and drive 1 in the lower bits,
so the #defines in /sys/isa/rtc.h specify the values for drive 0).

I /really/ need someone who understands device hints enough to
tell me what i'm doing wrong here. All my attempts to figure it
out myself were in vain.

. 2.88 MB still needs to be done.

OK, i've got a drive now, but still didn't get it to work. I
didn't want to defer this patch set any longer for this, however.
We've been living without 2.88 support for too many years already
anyway, now up to the point where they are already basically no
longer used.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message