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

    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

    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


    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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to