Dear LKML, Sam & I have been discussing his patch for formatting 1.44MB floppies in an LS-120 drive, and we decided to move the discussion out in the open. One of my concerns is that we don't take the ide-floppy driver in a different direction to the other removeable media drives. For Alan Cox, could you back out Sam's patch for now. It will be back soon. [Note to Richard Gooch, I haven't forgotten the devfs support] Sams patches, and the userspace formatting utility are available at http://www.email-scan.com/idefloppy/floppy-0.03.tar.gz Comments, suggestions etc would be welcome. This is the latest mail from Sam... Sam Varshavchik wrote: > > On Fri, 12 Jan 2001, Paul Bristow wrote: > > > > There are a couple of things that are new: > > > > > > * Ability to open the device even if there's no disk in the drive. This > > > is needed by the userspace app to probe the device. The open path sends a > > > START UNIT packet to the drive, and it looks like most LS-120 drives > > > report a sense error if there's no disk present. After thinking about it, > > > what I ended up doing is checking if the device is opened with O_EXCL flag > > > set, if so the open path will ignore a START UNIT failure. Everything is > > > still initialized correctly, and I've tested it -- this appears to work > > > quite well. I would prefer for the open path to always work without any > > > monkey business, like you can open /dev/fd even if there's no disk in the > > > drive. However, I'm not comfortable with that approach -- I'm pretty sure > > > lots of stuff in ide and hd drivers depend on open failing if there's no > > > actual disk present. I see this approach as the best compromise, since it > > > only affects the userland format utility, and nothing else. > > > > Let's put this suggestion out to the kernel mailing list. There are > > lots of other removeable media types out there and users will be > > terribly confused if they behave differently. > > Ok, but the alternatives are: > > 1) A separate minor device that will open whether or not there's a > formatted disk in the drive. I don't like this approach. > > 2) Forget the whole thing. This means that with some drives you will not > be able to format completely unformatted floppies, only reformat floppies > that are already formatted. > > The O_EXCL trick seems the cleanest way to be able to access the device > when you know what you're doing. The end result is that there needs to be > a way to access device with or without formattable media. > > > > * An additional flag bit on the packet structure to suppress logging an > > > error if the packet fails. The aforementioned dumb Matsushita drive > > > returns a sense error in response to IDEFLOPPY_CAPABILITIES_PAGE request. > > > This packet is only sent by my new code, and although this is not defined > > > as an optional feature of LS-120 drives, Matsushita does not appear to > > > implement it. Something like that normally results in the driver > > > reporting an I/O error to syslog. There isn't an actual problem, it's a > > > spurious error, so I'd rather suppress it instead of having people scream > > > about I/O errors in syslog. The new packet flag bit will only be used by > > > the format code. > > > > Hmm, isn't this only useful for debugging, and therefore belongs in > > IDEFLOPPY_DEBUG instead? > > See below. > > > > * Smarter handling of format progress reporting. Format progress > > > reporting is defined as optional in INF-8070. Something has to be done if > > > the drive doesn't support it. After sending FORMAT_UNIT to the drive, if > > > there's nothing else to be done the device will be closed from userland. > > > The close path sends an unlock packet to the drive. However, the drive > > > has just begun formatting the floppy, and it's going to be busy for a > > > while. ide.c will wait for the drive to become available, then give up > > > and do a bus reset. No good. > > > > Agreed. > > To check whether the device supports format progress reporting you need to > send a MODE_SENSE packet for the IDEFLOPPY_CAPABILITIES_PAGE. The deal is > that IDEFLOPPY_CAPABILITIES_PAGE itself appears to be optional (see last > paragraph on page 43 of INF-8070). This explains why this packet is > rejected by the drive. As I mentioned before, this error condition > results in the default error handler reporting an I/O error to syslog, > unless it's suppressed by that portion of my patch. > > One remote possibility is that I screwed up IDEFLOPPY_CAPABILITIES_PAGE, > and the drive is rejecting it for that reason. However, I note that the > definition of that packet already existed in 0.9, and Gabi's ChangeLog > mentions that he removed the code for that packet. I suspect the reason > was the same -- some drives reject it, causing errors logged to syslog. > > > My suggestion would be that we ask Alan Cox to reverse the patch he > > applied in ac4 for now, and then put some of these patches up onto the > > mailing list for comment. The reason is that I would like to get Clik! > > support into 2.4.1, and maybe devfs support too. If you don't mind I > > will put a pointer to your web page, and describe the work you are doing > > as experimental for now. > > That's fine. By the way: I didn't ask Alan to do anything -- he applied > the patch on his own. > > Also, feel free to simply forward my mail, with the patches, requesting > folks to comment on it. > > > If we had kernel 2.5 I would add it there without a qualm, but we don't > > for now, and Linus will be really pissed if we start breaking disks in a > > "stable" kernel. > > I'm not in any particular hurry. My primary motivation for doing this > hack is that I finally got pissed that I couldn't format floppies after > owning a couple of LS-120 drives for almost two years. That's all. > > Regarding the Clik drive -- I browsed that code briefly, for a minute or > two. You are checking the IDE model ID and selectively turning things off > that the Clik can't handle. > > Suppose that two months from now the Clik drive gets new firmware that > reports a slightly different model ID, say "IOMEGA Clik! 80 CZ ATAPI". > Or, perhaps, it's a new model of the Clik drive, that shares the same > shortcomings. Yep. Looks extremely possible. > It will become necessary to patch the detection code to check for the new > model ID. That may take another month or two before a new kernel comes > out, and even longer for the distribution to pick them up. > > I would use ioctls to selectively enable/disable portions of the driver's > functionality. A usermode app can grab the model ID using HDIO_GETGEO, > and configure the driver. Then, I would simply update the usermode app and > release it. No need to wait for a kernel rev. Even better is to add module parameters that can manually enable/disable features. I think the driver should solve problems it knows about (like Clik! drives) automatically. With more and more non-hackers starting to use Linux it has to be as friendly as we can make it. For new drives, there is then a chance that we can make them work just by adding an "options ide-floppy=no_lock_mechanism" line to /etc/modules.conf. If this isn't possible then it's a new driver/kernel/distro loop anyway. > Of course, I see some stuff needs to be done in driver init code, which > complicates things, but that's the general idea. > > -- > Sam Regards, -- Paul Email: [EMAIL PROTECTED] Web: http://paulbristow.net ICQ: 11965223 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
