Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!rice!uw-beaver!ssc-vax!bcsaic!paula From: paula@bcsaic.UUCP (Paul Allen) Newsgroups: comp.os.minix Subject: Re: 3.5" disks, PS/2 model 50Z Message-ID: <18698@bcsaic.UUCP> Date: 9 Jan 90 03:28:24 GMT References: <85654@linus.UUCP> Reply-To: paula@bcsaic.UUCP (Paul Allen) Organization: Boeing Computer Services AI Center, Seattle Lines: 136 In article <85654@linus.UUCP> gwr@linus.mitre.org writes: -In article <18528@bcsaic.UUCP> paula@bcsaic.UUCP (Paul Allen) writes: -[ Much deleted for brevity ] - -> I got tired of the glacial speed of the floppy driver under 1.3 and -> decided to add interleaving. - -[ discusses problems identifying media types ] - -> I've attacked my perceived problems in the 1.3 floppy driver with the -> following scheme: -> -> - The minor device number encodes the drive number, whether to -> use interleaving, and the drive/media combination. Given the -> drive/media code, one can look up stuff like the sectors per -> track and blocks per disk. -> -> - The 'd' (drive/media combination code) variable in floppy.c -> gets set by shifting and masking the minor device number. -> -> - The logic to try different values of 'd' is intact for the -> odd situation (like booting :-) ) when the requested minor -> device doesn't match the actual drive and media. I'd like -> to remove this and let an error just be an error. - -A good way to handle this is to add another minor device type which is -a "media sensitive" device useful for reading and writing formatted -diskettes. The other minor devices corresponding to particular -diskette formats would be useful with a diskette formatting program. Thanks, that's a good idea. And since you jogged my thinking cap, it occurs to me that the media type detection logic ought to be in the dev_open routine for floppy.c. Currently, both the dev_open and dev_close routines for major device 2 are null. If the floppy's dev_open and dev_close sent messages to the fs informing it of changes in the floppy's status, the 'size in the inode' mess would not be necessary. It would also not be necessary to read or write anything other than the 'media sensitive' device, as Gordon suggests. Now, will some wizard point out what's wrong with this? -> - A new subroutine fl_il() maps logical block numbers into -> physical block numbers and knows how to do 2:1 interleaving -> on 9- and 15-sector disks. I don't have any 3" drives, and -> haven't implemented 18-sector disk interleaving. - -Sector interleaving, as I understand it, should not necessitate any -change in the mapping of logical-to-physical disk blocks. [nice description of physical interleaving deleted] -With this understood, I think it would be a big mistake to re-map the -order of logical blocks to something other than sequential sector ID -numbers. Sector interleave should be the concern of the formatter. In general, I agree. However, interleaving via software is much easier to implement and accomplishes the identical result. (I only added about 20 lines to floppy.c and it worked first time.) One catch is that you need to know whether any given floppy was written with interleaving in order to read it. I consider this a small price, since essentially all of my floppies will be written interleaved from now on. Now, if someone wants to write a floppy formatting program for PC Minix, I would abandon my software interleaving scheme in a minute! Since the new /dev/port interface may not be fast enough for formatting floppies, the actual code to diddle the fdc may need to be in the kernel. That implies either a new system call or some ioctl() interface or... -> - The driver now returns EOF when the requested logical block -> is beyond the end of the media as specified by the minor -> device number. - [ see below ] -> -> - There are now quite a few floppy devices in /dev, and their -> names reflect the specific configuration encoded in their -> minor device numbers. The device special files were created -> with mknod, and do not contain sizes. -> -> I'm thinking about fixing the kernel so that the default minor device -> for floppy drive 0 specifies a 1.2M disk in a 1.2M drive without -> interleaving (my standard setup). It should probably be configurable -> via the makefile, or perhaps the default should be set based on what's -> in the drive at boot time. Anybody have any thoughts? - -Yes. Boot (and otherwise read) from the "media sensitive" device. - -> The bad news is that having the driver return EOF at the end of the -> volume doesn't have the same effect as putting the size in the inode. -> For example, GNU tar complains about a short write and aborts at the end -> of the first volume when writing a multi-volume archive. With the old -> driver and the old /dev/at0, gtar simply asked for the next volume to be -> mounted. - -Actually, the return value to use is not so simple. After studying -our Sun, Sys V/386, and GNU tar (by John Gillmore) it seems that -the following behavior is expected of an mtio(4) compatible device: - -+ Sequential reads past the end of the device should - return zero. (maybe EOF on subsequent reads?) - -+ Seek past the end should return error, EIO (I/O error). - -+ Sequential writes past the end of the device should - return error, ENOSPC (No space). If you ask Minix 1.3 (protected mode version) to write past the end of /dev/at0, the write() returns 0 and errno is also 0. It seems to me that the proper value would be ENXIO (no such device or address). The man page on my Sun documents ENXIO as including access beyond the end of a device. -> -> I've been poking around trying to find the place in the code that uses -> the inode size field to detect end-of-device, but haven't found it yet. - -Isn't the device size check done in kernel/floppy.c: do_rdwt() ? On a read, you can wait until the request gets down into the driver to check for access off the end of the media. On a write, however, the system call completes when the block gets put in the block cache. Therefore, the fs needs some way to detect end-of-media before handing requests off to the block cache. Putting the device size in the inode is one way. Having the floppy dev_open routine inform the fs about the current device size might be another. (If I've got things wrong here, I trust someone will set me straight.) I'll try some experiments tonight and post if I learn anything. -> Paul L. Allen | pallen@atc.boeing.com -Gordon W. Ross (E025) ARPA: gwr@linus.mitre.org Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen