Date: Sun, 7 Apr 1996 14:05:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-current@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: devfs questions Message-ID: <199604072105.OAA00599@phaeton.artisoft.com> In-Reply-To: <199604070649.QAA31787@godzilla.zeta.org.au> from "Bruce Evans" at Apr 7, 96 04:49:31 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> The change line is only valid while the motor is on, so it is almost > useless for automatic slice building. Consider the following setup: > > - fd0 motor off. > - all devices on fd0 closed. > - drive was previously opened, and it had slices fd0s1..fd0s4 on it, > and the slice driver has left these (possibly stale) devices in > the devfs tree for convenience (this is what it does now). > > What happens an attempt is made to open /dev/fd0s4 and /dev/fd0s4 has > gone away? Currently, the slice table is read and the open fails > because fd0s4 no longer exists, and fd0s4 disappears from the devfs > tree. This behaviour is right and wouldn't be significantly different > if the disk change line was supported - the slice table would be read > because the disk has changed instead of always like it is now. A reference to the /dev/fd0s4 device must force a validation of the /dev/fd0 device to determine if a media change has taken place. This is not a problem for an active disk, since the motor will be on the entire time. An allowable optimization may be to see if the motor is on, and if it is, assume no change. Note that this optimization is unnecessary for disks with real media change, but should work for those which don't. The format detection can be done by reading sectors 9 and 10 in a track, giving an error on the first read for an 8, an error on the second read for 9, and no error for 15 (obviously, this is extensible for n differing boundries for future support). The same algorithm can be used on sector 1 of differing tracks. Microsoft felt confident enough in this that the Windows95 "install format" media went out with a "non-standard" format. > The case where fd0s4 doesn't exist in the devfs tree but exists on the > disk after a disk change is more interesting/broken. Then there is > no way to reference /dev/fd0s4 without first opening /dev/fd0 or some > other existent slice or partition on fd0. Disk change line support > wouldn't be much used for fixing this because disk changes aren't > reported until you look. Yes, exactly. The "motor on" check can be used, as above, to optimize this. It means using broken hardware would be less optimial. I'd argue that broken hardware is intrinsically less optimal, so there is really no point in trying to do more than you can about it. > >> The first thing to do is to cause 0x370 referencing code to be added > >> to the floppy driver so that this is not a problem for 95% of all 3.5" > >> disks. > > >There's not much different between modern 3.5in and 5.25in drives. > >All AT drives are supposed to support changeline logic, and systems > >like OS/2 do break if the drives are broken. > > I have 2 out of 3 3.5in drives with broken change lines and 1 out of 3 > much older but less fragile 5.25in drives with broken change lines :-(. > This causes problems under DOS when I forget to hit ^C to tell it to > reset the disk. It used to cause problems under Linux. Linux now has > ioctls to disable the change line support. Installing new drives is > not an acceptable fix because I break things at install time :-). Any fix has to work with broken hardware, but it is acceptable to inconvenience the user in this case (make them type "changedisk" or put naked "^C"'s as a notifier into tcsh 8-)). For instance, it is inconvenient to have your Cyrix cache turned off, since the cache is there to help performance, but we all know that DMA writeback notification doesn't happen. For a system with bus master devices, turning of the cache is an "inconvenience", but not working is more of an inconvenience. We are not the source of the problem, the broken hardware is. Complaints should be taken up with the person who sold you the hardware, or, more preferrably, the person who bought it. Caveat Emptor. The ability to safely pop disks in and out at will on working hardware outwieghs ability to use a human as an index lookup into a device namespace instead of forcing the human to use a "changedisk" for the broken hardware. Consider "changedisk" to be the moral equivalent of forcing them to type "I acknowledge that I am trying to do something that shouldn't be possible with this broken hardware". Consider the results of the "changedisk" to be the system saying "here is the result you wanted as my thanks to you for acknowledging that you have crippled me with bogus hardware". You type ^C in DOS today to work around this hardware problem; all we are really arguing about now is number of keystrokes. Feel free to hack your shell. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604072105.OAA00599>