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