Date: Wed, 18 Jul 2001 23:48:31 +0200 From: Joerg Wunsch <j@uriah.heep.sax.de> To: hackers@freebsd.org, current@freebsd.org Subject: Large patchset for the floppy driver Message-ID: <20010718234831.D77455@uriah.heep.sax.de>
next in thread | raw e-mail | index | archive | help
Hello all, before leaving for vacation next week, i thought i'd put up the result of my work of the last couple of weeks for a review for those who are interested. The patch itself is available at http://people.freebsd.org/~joerg/fdpatch.txt.gz The following README file (see below) is also available at http://people.freebsd.org/~joerg/README.floppy Suggestions are welcome, but keep in mind that i won't have the opportunity to reply within ca. the next three weeks. ====================================================================== Many changes and improvements to the floppy driver. First of all, something i've meant to implement for years now, but never came around: automatic format (density) selection for the major medium formats. That is, you can stuff your 720 KB medium into your 1.44 MB drive, and simply access /dev/fd0. No questions asked, it will just handle it. :) (If you ever wondered why this didn't happen before, the answer is very simple: i needed the infrastructure to read a sector ID field before. That was one of the recent additions to the driver.) The driver can now handle FM floppies as well as MFM floppies. The NE765 commands in ne765.h have been redefined to no longer make implicit assumptions about MFM, SK, and MT; the driver adds those bits as required. The entire density handling subsystem with its bloated list of different possible media density and its twisted decisions about which drive can handle what has been completely moved out of the kernel, into fdcontrol(8) where it should have been all the time. It's very simple, the basic device (four low order bits equal 0) is the subdevice with automagic density selection, and subdevices 1 through 15 are available for fixed density assignments. By default, all of the latter are being initialized to the drive's maximum possible density. It's up to fdcontrol(8) to customize those subdevices. Subdevice naming has been liberalized; subdevices `a' through `h' are still implemented as pseudo-partitions which just cause a symlink to be created to the master device. Subdevices of the form .NNNN can be arbitrarily created, where .NNNN means between 1 and 4 digits. So you can now either create your subdevices like fd0.1 through fd0.15, or you can still name them by density (as it used to be now, but with a fixed set of allowable names), as in fd1.800 etc. Automagic density selection honors the unit attention bit (aka. changeline signal). It is checked in Fdopen(), and if it is set, the autoselection is started. If you re-open the same device without changing media, no new autoselection is initiated. Some old hacks have been made right, now that the infrastructure seems to be in place. There's no longer a configuration flag to fdc(4) that tells there should be a single 1.44 MB drive assumed without probing. On non-i386 architectures, there's no longer an assumption that all the world is an 1.44 MB drive; on i386 architectures there's no longer the assumption that you could only have two drives that need to be mentioned in the RTC (although you need more than one controller for more drives, and i haven't tested that yet). Drive configuration is now handled through device hints and a `flags' value per drive: the lower 4 bits define the drive type (like in i386 RTC, but shifted right by 4), bit 0x10 disables changeline support, bit 0x20 forces the device to probe successfully without making a seek test first. On i386 architectures, if the device type hasn't been set by the flags, and the fd unit number is 0 or 1, the CMOS RTS is still queried as it used to be (but you could now override this). (Detection of the i386 architecture has been changed to test for _MACHINE_ARCH instead of testing whether we are compiling on __i386__.) O_NONBLOCK handling has been added to support formatting on a device that is normally using density autoselection. Obviously, you cannot autoselect the density of an unformatted medium :), so O_NONBLOCK seemed to be the best way out. Only a limited subset of ioctls is possible in nonblocking mode, then you need to clear the flags with fcntl in order to perform actual IO. Some things in the density structure have been changed: there certainly won't be more than two steps between cylinder, so we can singly fold this feature into a flag bit, where the remaining bits can be used otherwise (currently for MFM vs. FM, and for perpendicular recording which is needed for 2.88 media). There's now a field that allows to specify an offset for the sector numbers on side 2; some very old media used to be formatted that way (and Bruce Evans still has some :). A number of further ioctls have been added to obtain driver and device information. Used in fdcontrol and fdformat. fdcontrol(8) has been heavily rewritten. Densities can be specified in kilobytes, and will then be selected from per-drive type tables, or they can be specified as a feature string (currently only explained in fdsupport.c). A feature string is a comma-separated list of numbers and flag values, where any omitted value defaults to the setting that is currently present (or has been assigned by -f <format in kilobytes> before). The same consistent handling (using the same functions) has been integrated into fdformat(1), replacing all the options there that used up almost all the letters of the abc... ;-) Both utilites now use sysexits(3) for their exit values. TODOs and known Bugs: Some rc script needs to be written to auto-assign twisted density definitions (as we used to have by now) to the various devices. The infrastructure is there, if you just call "fdcontrol /dev/fd0" you get a short description of the drive type (1.44M, 360K etc.), so the rc script can poll all /dev/fd? devices, and call fdcontrol with an appropriate list of possible densities for that drive type. (It should also optionally chmod g+w all those devices, since floppy disk usage is quite more comparable to tape usage than to disk device usage.) The attempt to obtain drive flags from the hints currently fails, and always returns 0. I'm doing something seriously wrong there, but by now could not find /what/. Thus, all the nitty-gritty details about drive flags currently Just Don't Work[tm]. 2.88 MB floppies need to be handled. Should i ever get my 2.88 drive to work, i'll do that. By now, they are ifdef'ed out to 1.44 everywhere. All documentation updates still need to be written. fdwrite(1) needs to be checked whether some of the fdformat(1) changes apply there as well. KLD loading of fdc.ko by now only works for the Y-E data PCMCIA floppy, or for ISA FDCs if you load the KLD first time from within the FORTH loader. Unloading and re-loading it later works then. This seems to be some bug with the bus resource handling, and/or hints processing. Something is totally fishy with formatting on 1.2 MB drives. Maybe it's just the drive i'm using for testing, i don't know. Neither DD or HD media formatted correctly for me, although a 1.44 MB drive on the same controller worked. Formatting weird formats sometimes seems to produce surprises. An attempt to format a 26*128 FM floppy (on a 3.5" DD medium) yielded only head 1 sector IDs recorded, and only wrong cylinder numbers. Needs a bit more investigation. Could be related to the 1.2 MB drive formatting problem. Device hints need to be changed (in particular on !i386 architectures). Of course, this requires that we properly detect the drive flags from the hints first. ;-) -- 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010718234831.D77455>