Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
On Thu, Sep 14, 2000 at 09:22:09PM +0200, Bombeeck, Jack wrote: > So st should reject those devices that are serviced by > osst. Couldn't we just let osst claim them first or is > that too simple? I think that letting st claim (under any circumstances) a device which it can't handle is a mistake. It's going to lead to user confusion and other uglyness. If st can't handle the device, it shouldn't try. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 PGP signature
RE: PATCH: ide-scsi.c to allow claiming of Onstream drives
Hi Andre, Sorry for not keeping you up to date properly! I thought you were already following the osst mailing list activity (http://linux1.onstream.nl). In any case, the idea is _not_ to get rid of ide-tape, but rather to get the maximum out of osst that we can. Ofcourse, using the one driver for all scsi, ide and usb drives with a QIC172 command set will make tapes completely interchangeable by default, which is nice. And the 'ide disconnect' emulation is just a corollary of our Windows activities after a sudden brainwave when the existing ide-scsi emulation layer was mentioned. The ide-tape driver still has some special features -like the pipeline- that can make it a more attractive choice for some users. So it's still on my wish list to have the logical format of ide-tape adapted to be identical to the latest one that osst uses. And finally, we'll be having more 157 devices soon, in an IDE version first, perhaps followed by SCSI and USB afterwards (not decided on, so don't quote that). The idea is that st should work without any changes, in conjunction with ide-scsi or usb-storage as appropriate. So st should reject those devices that are serviced by osst. Couldn't we just let osst claim them first or is that too simple? Similarly for ide-tape and ide-scsi + osst. If whoever comes first services the drive, then the other driver can still be loaded for other devices. I suppose it would have to be made very clear to the user how to obtain the correct load order. cheers, Jack -Original Message- From: Andre Hedrick To: Willem Riede Cc: Matthew Dharm; Gadi Oxman; Linux SCSI list; Kernel Developer List; Linus Torvalds; Kai Makisara; Bombeeck, Jack Sent: 14-9-00 1:53 Subject: Re: PATCH: ide-scsi.c to allow claiming of Onstream drives > The second patch that Matt refers to inserts that logic into st so > it does not try to support these drives and fails due to the drive > particulars. Since SCSI, USB and IDE versions of these drives exist, > patching st is more appropriate than ide-scsi. Okay I am a mushroom, keep feeding me crap and I will stay in the dark. ;-) If this is the case go for it! I just hadn not heard anything from Jack Bombeeck but regardless, if it is covered and it will detect the differenct in headers and reject as neede, cool. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
RE: PATCH: ide-scsi.c to allow claiming of Onstream drives
Hi Andre, Sorry for not keeping you up to date properly! I thought you were already following the osst mailing list activity (http://linux1.onstream.nl). In any case, the idea is _not_ to get rid of ide-tape, but rather to get the maximum out of osst that we can. Ofcourse, using the one driver for all scsi, ide and usb drives with a QIC172 command set will make tapes completely interchangeable by default, which is nice. And the 'ide disconnect' emulation is just a corollary of our Windows activities after a sudden brainwave when the existing ide-scsi emulation layer was mentioned. The ide-tape driver still has some special features -like the pipeline- that can make it a more attractive choice for some users. So it's still on my wish list to have the logical format of ide-tape adapted to be identical to the latest one that osst uses. And finally, we'll be having more 157 devices soon, in an IDE version first, perhaps followed by SCSI and USB afterwards (not decided on, so don't quote that). The idea is that st should work without any changes, in conjunction with ide-scsi or usb-storage as appropriate. So st should reject those devices that are serviced by osst. Couldn't we just let osst claim them first or is that too simple? Similarly for ide-tape and ide-scsi + osst. If whoever comes first services the drive, then the other driver can still be loaded for other devices. I suppose it would have to be made very clear to the user how to obtain the correct load order. cheers, Jack -Original Message- From: Andre Hedrick To: Willem Riede Cc: Matthew Dharm; Gadi Oxman; Linux SCSI list; Kernel Developer List; Linus Torvalds; Kai Makisara; Bombeeck, Jack Sent: 14-9-00 1:53 Subject: Re: PATCH: ide-scsi.c to allow claiming of Onstream drives The second patch that Matt refers to inserts that logic into st so it does not try to support these drives and fails due to the drive particulars. Since SCSI, USB and IDE versions of these drives exist, patching st is more appropriate than ide-scsi. Okay I am a mushroom, keep feeding me crap and I will stay in the dark. ;-) If this is the case go for it! I just hadn not heard anything from Jack Bombeeck but regardless, if it is covered and it will detect the differenct in headers and reject as neede, cool. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
On Thu, Sep 14, 2000 at 09:22:09PM +0200, Bombeeck, Jack wrote: So st should reject those devices that are serviced by osst. Couldn't we just let osst claim them first or is that too simple? I think that letting st claim (under any circumstances) a device which it can't handle is a mistake. It's going to lead to user confusion and other uglyness. If st can't handle the device, it shouldn't try. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver G: Let me guess, you started on the 'net with AOL, right? C: WOW! d00d! U r leet! -- Greg and Customer User Friendly, 2/12/1999 PGP signature
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
> The second patch that Matt refers to inserts that logic into st so > it does not try to support these drives and fails due to the drive > particulars. Since SCSI, USB and IDE versions of these drives exist, > patching st is more appropriate than ide-scsi. Okay I am a mushroom, keep feeding me crap and I will stay in the dark. ;-) If this is the case go for it! I just hadn not heard anything from Jack Bombeeck but regardless, if it is covered and it will detect the differenct in headers and reject as neede, cool. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
Andre Hedrick wrote: > > On Wed, 13 Sep 2000, Matthew Dharm wrote: > > > Attached is a patch to ide-scsi.c against 2.4.0-test8. Please consider > > applying it. > > > > This patch removes the logic which causes ide-scsi to refuse to attach > > itself to an IDE OnStream drive. While these drives are not supported by > > the standard st.c driver, there is userspace support (using the sg > > interface) which works with the ATAPI drive with ide-scsi patched with this > > patch. > > > > So there really is no reason for ide-scsi to reject this device. > > Yes, > > There is a reason that it was put there, DI-30's require special IO that > st.o does not know how to do. > > Look at all the hoops that it took to get ide-tape to work. > If ide-scsi would have done the trick, it would have saved headaches. Indeed. But in the mean time, a scsi driver for Onstream drives has been written (by me). Together with Kai Makisara I have resolved how to get those drives detected by this new driver (osst) and not by st. The second patch that Matt refers to inserts that logic into st so it does not try to support these drives and fails due to the drive particulars. Since SCSI, USB and IDE versions of these drives exist, patching st is more appropriate than ide-scsi. Regards. Willem Riede. - 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/
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
On Wed, Sep 13, 2000 at 03:53:13PM -0700, Andre Hedrick wrote: > > On Wed, 13 Sep 2000, Matthew Dharm wrote: > > > Attached is a patch to ide-scsi.c against 2.4.0-test8. Please consider > > applying it. > > > > This patch removes the logic which causes ide-scsi to refuse to attach > > itself to an IDE OnStream drive. While these drives are not supported by > > the standard st.c driver, there is userspace support (using the sg > > interface) which works with the ATAPI drive with ide-scsi patched with this > > patch. > > > > So there really is no reason for ide-scsi to reject this device. > > Yes, > > There is a reason that it was put there, DI-30's require special IO that > st.o does not know how to do. > > Look at all the hoops that it took to get ide-tape to work. > If ide-scsi would have done the trick, it would have saved headaches. > > Unless OnStream has changed the firmware it will fail, but please try. I am well aware of the fact that st.c is unable to suppor this drive. It's also unable to support the OnStream SC-30 and SC-50 units. Realistically, st should reject these drives -- work is being done on a patch to st do accomplish this. However, the userspace solution (which uses the scsi generic interface) _will_ work with the ATAPI drive under ide-scsi emulation. There is also an (experimental) kernel driver (called osst) which will do the work of st -- this driver works with the SC-30, SC-50, and DI-30 (ATAPI) units. Of course, the only way either the osst or sg driver will work with my ATAPI drive is if ide-scsi will do the emulation. I should point out that I've tested this configuration, and it works well. Unfortunately, ide-tape and these other drivers (both sg and osst) use different logical formats on the tape. Tapes made on my ATAPI drive with osst + ide-scsi are unreadble by ide-tape. However, they are readable on SCSI units (and should be readble with USB units as soon as I'm done with that driver). The point is, there is no reason for ide-scsi to refuse to do the emulation. I personally find that emulation useful to do backups with. There _is_ a reason for st.c to reject these OnStream drives, but that logic belongs in st.c, not in ide-scsi.c Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver You should try to see the techs say "three piece suit". -- The Chief User Friendly, 11/23/1997 PGP signature
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
On Wed, 13 Sep 2000, Matthew Dharm wrote: > Attached is a patch to ide-scsi.c against 2.4.0-test8. Please consider > applying it. > > This patch removes the logic which causes ide-scsi to refuse to attach > itself to an IDE OnStream drive. While these drives are not supported by > the standard st.c driver, there is userspace support (using the sg > interface) which works with the ATAPI drive with ide-scsi patched with this > patch. > > So there really is no reason for ide-scsi to reject this device. Yes, There is a reason that it was put there, DI-30's require special IO that st.o does not know how to do. Look at all the hoops that it took to get ide-tape to work. If ide-scsi would have done the trick, it would have saved headaches. Unless OnStream has changed the firmware it will fail, but please try. > A future patch to make st.c reject OnStream drives it is unable to support > if coming soon. > > Matt > > -- > Matthew Dharm Home: [EMAIL PROTECTED] > Senior Engineer, QCP Inc.Work: [EMAIL PROTECTED] > > G: Let me guess, you started on the 'net with AOL, right? > C: WOW! d00d! U r leet! > -- Greg and Customer > User Friendly, 2/12/1999 > Andre Hedrick The Linux ATA/IDE guy - 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/
Re: PATCH: ide-scsi.c to allow claiming of Onstream drives
The second patch that Matt refers to inserts that logic into st so it does not try to support these drives and fails due to the drive particulars. Since SCSI, USB and IDE versions of these drives exist, patching st is more appropriate than ide-scsi. Okay I am a mushroom, keep feeding me crap and I will stay in the dark. ;-) If this is the case go for it! I just hadn not heard anything from Jack Bombeeck but regardless, if it is covered and it will detect the differenct in headers and reject as neede, cool. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
