Re: ide-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]
> One of my concerns is that we don't take the ide-floppy driver in a > different direction to the other removeable media drives. In general the others do it raw via scsi commands and sg. > For Alan Cox, could you back out Sam's patch for now. It will be back > soon. When the new one is sorted. I'm not going to feed it to Linus anyhow. For the moment there are quite a few people glad of it > > > > * 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 Other devices allow this for O_NDELAY only. > > 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. Ugly. Thats a lot of extra devices. > > The O_EXCL trick seems the cleanest way to be able to access the device Use the same O_NDELAY cdroms do > > 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. Nod. I've already suggested a seperate blacklist table of device id/flaws as SCSI does - 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/
ide-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]
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
ide-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]
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
Re: ide-floppy [Fwd: Updated ATAPI FORMAT_UNIT patch.]
One of my concerns is that we don't take the ide-floppy driver in a different direction to the other removeable media drives. In general the others do it raw via scsi commands and sg. For Alan Cox, could you back out Sam's patch for now. It will be back soon. When the new one is sorted. I'm not going to feed it to Linus anyhow. For the moment there are quite a few people glad of it * 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 Other devices allow this for O_NDELAY only. 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. Ugly. Thats a lot of extra devices. The O_EXCL trick seems the cleanest way to be able to access the device Use the same O_NDELAY cdroms do 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. Nod. I've already suggested a seperate blacklist table of device id/flaws as SCSI does - 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/
