search

PiSCSI / piscsi

PiSCSI allows a Raspberry Pi to function as emulated SCSI devices (hard disk, CD-ROM, and others) for vintage SCSI-based computers and devices. This is a fork of the RaSCSI project by GIMONS.
https://piscsi.org
BSD 3-Clause "New" or "Revised" License
545 stars 82 forks source link

Add the SCSI version as a configuration option #1110

Closed akuker closed 1 year ago

akuker commented 1 year ago

Info

There have been a couple point solutions (#828 and #1109) to add support for SCSI-1 in the inquiry response. These solutions work for HD's and CD's, but this should expanded to all device types and should not be based upon file name extension.

Proposed solution is to add a configuration parameter, similar to the Vendor/Product/Revision options, that allows the SCSI version to be specified. This should be an option that applies to all devices, not just HD and CD.

The web interface should also be updated to allow the user to select which SCSI version.

akuker commented 1 year ago

We should look at making a generic configuration input that allows the user to specify key/value pairs as configuration options. We're getting a lot of command line arguments in scsictl.

Something like: (-a for argument, maybe... there aren't many letters left) scsictl -c attach -i 3 -f ~/images/drive.hda -a SCSI_VERSION:1 -a AKAI_QUIRKS:1

(Akai quirts talked about in #741)

uweseimet commented 1 year ago

@akuker Are there any real-world scenarios (user reports with other devices than hard disk or CD-ROM drives) where the current solution is not sufficient? Most device types were introduced with SCSI-2 as far as I can tell, i.e. they cannot be SCSI-1. From that perspective https://github.com/PiSCSI/piscsi/pull/1109 should be sufficient.

uweseimet commented 1 year ago

I suggest to close this issue as "won't" do, based on my last comment: There are no other SCSI-1 device types than the ones already covered.

rdmark commented 1 year ago

@uweseimet I agree that introducing a SCSI level selection right now isn't high priority, since the known corner cases have been covered by the special file ending code paths now. I suggest we revisit this if unhandled SCSI level corner cases are discovered.

I still think it's worth discussing quirks mode in general as @akuker suggests. We have one major pending compatibility issue with a known workaround (see https://github.com/PiSCSI/piscsi/issues/741 ) that may benefit from introducing a quirks mode option. Thoughts?

uweseimet commented 1 year ago

@rdmark IMHO this is not primarly about priorities. PiSCSI should not emulate SCSI-1 device types that have never existed, because (unless somebody proves the opposite) there is no computer that would expect such a device.

Regarding any kind of quirks mode you might end up with a bunch of work-arounds where nobody knows which mode to use when, and what it means to have a combination of these modes. The original RaSCSI code contained many strange work-arounds, and instead of improving compatibility they just did the opposite. Often when you think a work-around is needed in practice this indicates that the underlying problem has not fully been analyzed. In the case of https://github.com/PiSCSI/piscsi/issues/741, why would artifically slowing down the rate at which PiSCSI executes commands be an improvement? I bet no real SCSI device vendor ever did that, but they were interested in their devices executing commands as fast as possible. From that perspective I wonder why MIN_EXEC_TIME is there at all, and I doubt that changing its value is the right solution. I rather think the core of the problem has not sufficiently been analyzed. And users are still waiting for feedback on their SCSIMON logs, as far as I can tell.

akuker commented 1 year ago

Withdrawing this ticket.